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ABSTRACT 

The  main  r,oal  of  this  thesis  is  to  study  the  perfor¬ 
mance  tradeoffs  between  parallelism  and  increased  con¬ 
currency  control  overhead  during  simultaneous  user  updates 
of  a  database.  During  such  updates,  a  database  management 
system  must  guarantee  that  the  multiple  users  do  not 
interfere  with  each  other. 

The  potential  advantages  of  parallelism  in  accessing 
a  database  include  the  better  utilization  of  com outer 
resources  and  better  response  times  for  users.  Those 
advantages,  however,  may  be  offset  by  the  increased  use  of 
system  resources  to  irsure  that  there  is  no  interference 
between  the  multiple  users.  Simulation  models  are  used  to 
study  these  two  conflicting  asnects  of  concurrency  control 
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for  both  centralized  and  a  d  i  st  r  i  buted  databases. 

One  of  the  most  imoortant  desigr  decisions  irvolves 
locking  granularity.  Locking  granularity  refers  to  the 
size  and  hence  the  number  of  locks  maintained  by  the  data¬ 
base  management  system.  The  centralized  database  simula¬ 
tion  results  indicated  that  in  many  cases,  in  particular 
if  data  access  is  primarily  sequential,  coarse  granularity 
such  as  file,  relation  or  record  type  locking  is  prefer¬ 
able.  However,  if  all  of  the  updates  are  small  ar.d  ran¬ 
domly  access  the  database,  finer  granularity,  such  as  page 
or  record  locking  becomes  necessary.  If  the  sizes  ard 
access  oatterr.s  of  updates  vary  considerably,  the  simula¬ 
tion  results  indicated  that  a  lock  hierarchy  with  dif¬ 
ferent  siz.ed  locks  is  beneficial. 

In  a  distributed  database,  the  data  is  stored  or:  dif¬ 
ferent  computer  sites  connected  through  some  type  of  net¬ 
work.  In.  such  a  system,  some  of  the  database  activities 
are  local  in.  that  they  only  involve  data  at  one  site. 
Other  database  activities  are  distributed  in  that  they 
involve  data  at  several  of  the  computer  sites.  >  In  a  dis¬ 
tributed  database,  increased  parallelism  is  possible  dur¬ 
ing  simultaneous  database  activities.  However,  the  cor - 
currency  control  overhead  may  also  ircrease.  The  simula¬ 
tions  modeled  a  variety  of  cor  currency  control  algorithm's 
to  study  the  additional  tradeoffs  in  a  distributed  data- 


In  particular,  primary  site  control  and  decentralized 
control  algorithms  were  simulated.  In  the  primary  site 
control  algorithms,  ore  site  performs  the  concurrency  con¬ 
trol  functions  for  all  of  the  other  sites.  In  the  decen¬ 
tralized  control  algorithms,  the  concurrency  functions  are 
distributed  to  each  of  the  sites  and  special  provisions 
must  be  used  to  prevent  or  detect  deadlock. 

The  simulation  results  indicated  that  with  a  high 
speed  network  and  mostly  local  database  activities,  either 
concurrency  control  approach  is  accentable.  As  the  net¬ 
work  becomes  slower,  the  decentralized  control  algorithms 
are  preferable.  If  most  of  the  database  activities  are 
distributed,  however,  the  primary  site  approach  can  take 
advantage  of  its  "global"  knowledge  to  better  schedule  the 
processing  of  transactions  and  thus  provide  better  perfor¬ 
mance  than  the  decentralized  algorithms. 

These  results  can  provide  insights  into  the  design 
and  implementation  of  the  concurrency  cor trol  mechanisms 
for  a  wide  variety  of  centralized  and  distributed  database 


management  systems. 
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CHAPTER  1 


INTRODUCTION 

1-  PATABASE  CONCURRENCY  CONTROL 

One  of  the  major  features  of  a  database  management 
system  is  to  allow  multiple  users  access  to  shared  data. 
During  such  multiple  user  access  (and  update),  the 
"integrity"  of  the  database  must  be  guaranteed.  The 
mechanism  which  guarantees  that  "integrity"  is  commonly 
referred  to  as  the  concurrency  control  subsystem  of  a 
database  management  system. 

Two  conflicting  aspects  of  the  concurrency  control 
mechanism  affect  the  performance  of  a  database  management 
system.  On  the  ore  hand,  the  concurrency  control  can 
increase  the  parallelism  allowed  in  accessing  the  data¬ 
base.  On  the  other  hand,  the  advantages  of  such  increased 
parallelism  may  be  offset  by  the  amount  of  system 
resources,  or  overhead,  that  are  used  to  irsure  database 
integrity. 

The  main  goal  of  this  thesis  is  to  study  the  perfor¬ 
mance  trade-offs  between  increased  parallelism  and 
increased  concurrency  control  overhead  ir.  order  to  provide 
insights  for  concurrency  control  implementations  in 
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?. 

database  mar:  axemen  t  systems. 

Jr  the  remain  Jer  of  this  ihaoter,  some  of  the  prob¬ 
lems  i  r:  database  core  urrer  cy  cortrol  are  di  so  us  sod  ar  d  the 
previous  research  results  or  the  performance  evaluatior  of 
cor  currency  cortrol  mechanisms  are  reviewed. 

2.  CONCURRENCY  CONTROL  PROBLEMS 

2 . 1 .  Databasie  <2°_ri?L:'-5^r:Ly 

The  database  concurrency  cortrol  subsystem  is  resDor- 
sible  for  the  integrity  ard  cor.sistercy  of  the  database 
during  multiple  user  updates.  The  following  example 
illustrates  the  type  of  inconsistencies  which  can  arise 
without  concurrency  controls. 

One  user  is  producing  a  summary  report  of  the  total 
salaries,  taxes  and  benefits  that  are  paid  for  a  ^iver  pay 
period.  At  the  same  time  some  other  user  is  updating 
individual  payroll  records  for  the  "next"  payroll. 
Without  some  type  of  concurrency  cortrol,  the  summary 
report  may  include  some  data  from  the  "previous"  payroll, 
and  some  from  the  "next"  payroll.  Thus,  the  results  of 
that  report  would  rot  accurately  reflect  either  the  previ¬ 
ous  or  next  payroll  periods. 

Furthermore,  the  report  may  rot  accurately  reflect  an 
individual's  payroll  record  for  either  pay  period.  Sup- 
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pose,  for  example,  that  employee  x's  payroll  record  was 
beinr,  updated.  The  summary  report  miqht  cortair  the  rew 
salary  but  the  old  tax  ard  benefit  values. 

The  concept  of  "database  consistency"  refers  to  the 
permissible  states  of  a  database.  The  states  which  are 
permissible  may  require  certain  rel at  ion sh i ps  between 
various  elements  in  the  database.  For  example,  one  such 
requirement  may  be  that  a  department  salary  total  must 
equal  the  sum  of  all  of  the  individual  salaries  ir.  the 
department.  Such  constraints  are  application  dependent 
and  thus  difficult  to  define  for  a  general  database 
management  system. 

In.  [ESWA76],  the  concepts  of  transactions  and  serial 
schedules  are  introduced.  A  "transaction"  is  a  set  of 
related  atomic  actions  involving  a  database  which,  if  run 
alone  on  a  database,  preserves  database  consistency.  A 
"schedule"  for  processing  transactions  is  a  sequence  of 
atomic  actions  from  the  transactions.  A  "serial  schedule" 
is  one  in  which  all  the  atomic  actions  from  one  transac¬ 
tion  are  scheduled  first,  followed  by  all  of  the  atomic 
actions  from  a  second  transaction,  etc.  In  other  words, 
the  transactions  are  run  one  at.  a  time  aqainst  the  data¬ 
base  . 

A  transaction  schedule  is  "serializable"  if  the 
effects  of  the  atomic  actions  in  the  scheduled  order  are 


!) 

equivalert  to  rurr  ir  <»  the  transactions  i  p  some  serial 
schedule.  If  p,Kh  trarsav.-t.ior  preserves  the  cor  si  store  y 
of  the  database,  it  is  clear  that  a  serial  schedule,  ar:d 
thus  a  serializable  schedule,  must  also  preserve  the  cor- 
si  storey  of  the  database. 

Two  protocols  for  transaction  behavior  are  defined  ir: 
[KSWA761  which  are  used  to  insure  the  ser  i  a  1  i  zab i 1 i ty  of 
any  schedule.  A  trarsactior.  is  said  to  be  "well-formed" 
if  all  transactions  acquire  a  lock  (read  or  write  [DTJK68, 
COURT!])  before  touchier,  (reading  on  writin.fi)  an  object  of 
the  database.  A  trarsactior:  is  said  to  be  "  two-pba  sed "  if 
it  acquires  all  of  its  locks  before  releasing  any  locks. 

If  all  transactions  are  two-phased  and  well-formed, 
[FSWA76]  shows  that  ar.y  schedule  of  atomic  actions  that 
does  rot  violate  the  required  locking  protocols  is  serial¬ 
izable  and  thus  preserves  the  consistency  of  the  database. 

Some  database  management  systems  support  weaker  forms 
of  consistency  where  the  applications  may  allow  for  cer¬ 
tain  violations  of  the  well-formed  and  two-phased  proto¬ 
cols  [CRAY7&].  It  has  also  been  shown  [PFRN7S1  that  seri¬ 
alization  (or  effec  tive  serial izatior  )  of  trarsactior  s  is 
sometimes  unnecessary.  Throughout  this  study,  however,  it 
is  assumed  that  the  concurrency  control  subsystems  require 
that  transactions  are  we  1 l - f ormed  ard  two-phased. 


?.?.  Deadlock  and  Rollback 

Those  two  protocols  do  provide  solutions  to  some  of  the 
concurrency  control  problems.  However,  other  problems 
which  the  concurrency  control  subsystem  must  still  solve 
ipclude  deadlock  resolution  arid  the  problem  of  cascading 
rollback  of  transactions. 

A  simple  example  can  be  used  to  illustrate  the 
deadlock  problems.  Suppose  one  transaction  locks  and 
writes  object  A  and  another  transaction  similarly  locks 
and  writes  object  R.  Then,  the  first  transaction  requests 
a  lock  on  R  while  the  second  transaction  requests  a  lock 
on  A.  The  four  conditions  for  deadlock  [C0FF71]  are  met 
since  neither  transaction  can  release  its  existing  locks 
without  violating  the  two-phased  locking  protocol.  Thus, 
a  concurrency  control  scheme  must  solve  deadlock  problems 
by  either  prevention  or  detection  and  resolution. 

If  deadlock  detection  and  resolution  is  used  it  may 
be  necessary  to  roll  back  or  undo  the  effects  of  a  tran¬ 
saction.  Note  that  if  locking  is  not  two-phased,  some 
other  transaction  may  read  the  effects  of  a  transaction 
which  has  beer  rolled  back.  In  this  case  the  other  tran- 
sactior  must  also  be  rolled  back.  (Otherwise,  the  updates 
of  the  rolled  back  transaction  might  still  appear  ir  other 
parts  of  the  database). 


This  corditior  is  called  "cast  adir  g"  rollback  ar.d  c  ar 


be  generated  ever  if  two  phased  locking  is  enforced.  A 
tr an  sac t  i  or  may  also  he  rolled  back  because  of  a  change  in 
a  user's  mind,  or  because  of  a  hardware  problem.  If  that 
transaction  had  neleased  some  of  its  write  locks,  other 
transactions  might  also  have  to  be  rolled  back.  To 
prevent  this  cascading  rollback,  man  v  database  systems 
hold  all  locks  until  the  er  d  of  the  trnrsactior  .  1  r.  fact, 
all  of  the  concurrency  eortrol  subsystems  considered  in 
this  study  will  require  that  leeks  be  held  until  the  end 
of  a  trar  sactior . 

2.3.  Database  Operating  System  Corcurrer  «._y 

The  concurrency  control  requirements  for  databases 
are  different  than  the  concurrency  eortrol  requ  i  remer  t.s 
for  operating  systems.  One  difference  is  that  an  operat¬ 
ing  system  controls  simultaneous  access  to  fixed  objects; 
such  as  line  printers,  tape  drives,  specific  addresses  ir. 
core,  etc.  A  database  system,  or:  the  other  hard,  cortrols 
access  to  objects  whose  names  arid  addresses  car  change. 

Another  difference  is  that  more  objects  need  to  be 
locked  in  a  database  management  system.  The  database  may 
c.ortair  milliors  of  objects,  such  as  records,  field 
values,  etc.,  which  have  to  be  locked.  The  number  of  dif¬ 
ferent  objects  that  car  be  locked  ir  an  oneratirg  system 
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is  gererallv  much  smaller. 

3.  PRRV_I_OUS  PERFORMANCE  R£SIJLTS 

The  results  of  the  above  problems  and  consistency 
requirements  have  resulted  in  a  wide  variety  of  different 
concurrency  control  mechanisms.  The  goal  of  this  thesis, 
however,  is  not  to  develop  new  concurrency  control  algo¬ 
rithms,  but  to  study  the  affects  of  various  concurrency 
control  strategies  on  the  overall  performance  of  the  data¬ 
base  management  system  by  means  of  simulation  models. 
Previous  work  in  this  area  can  be  divided  into  centralized 
databases,  where  the  entire  database  is  maintained  by  one 
computer;  and  distributed  databases,  where  the  database  is 
distributed  across  several  computers  connected  by  some 
type  of  network. 

3 . 1_.  Centralized  Databases 

In  [NAKA75]  a  simulation  model  is  used  to  study  the 
performance  of  a  database  system.  A  database  system  model 
and  synthetic  user  application  models  were  run  to  estimate 
system  utilizatiors  arid  average  response  times.  One 
result  observed  was  that  the  system  bottlenecked  due  to 
the  delays  caused  by  concurrent  updates.  When  the  con¬ 
current  updates  were  administratively  removed  from  the 


at>Dl  icatior  model  (to  presumably  bo  rur  at  r.  io.ht)  ,  the 
average  respoi  se  time  decreased  bv  a  factor  of  sever.. 
Sirce  rot  all  appl  icatior  s  allow  for  administrative  vor- 
currer.vy  cortrol,  it  is  clear  that  corc-urrer  cv  control 
mechar:isms  can  significantly  affect  the  overall  perfor¬ 
mance  of  the  database  management  system. 

Several  other  simulation  studies  have  also  explored 
the  effects  of  concurrency  control  or  database  system  per¬ 
formance.  In  [SPIT76]  the  effect  of  scheduling  the  lock 
requests  and  releases  for  the  System  ?000  database  manaq,e- 
rnent  system  was  examined.  In  that  study,  the  difference 
between  locking  the  database  for  the  entire  period  of  a 
transaction,  as  opposed  to  lock in o  and  unlocking  the  data¬ 
base  for  each  atomic  update  was  surprisingly  small.  The 
additional  parallelism  possible  with  the  short  locks  was 
offset  bv  the  additional  time  spent  by  the  transactior s 
waiting  for  that  lock. 

In  [MUN77]  several  parameters  and  concurrency  cortrol 
alternatives  were  explored  by  means  of  a  simulatior  model. 
In  that  simulatior  ,  alternate  methods  for  chocs in"  a  vic¬ 
tim  in  deadlock  resolution  were  explored.  The  results  of 
the  simulatior  showed  t.hat  three  methods  for  selecting  a 
victim  were  superior:  1)  the  victim  should  be  the  process 
which  accessed  the  least  amour t  of  data,  ?)  the  victim 
should  be  the  process  which  hold  the  fewest  number  of 
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locks;  or  3)  the  victim  should  be  the  process  which  had 
used  the  least  amount  of  computer  resources. 

In  addition  to  deadlock  resolution,  the  [MUN77J  simu¬ 
lation  was  used  to  study  the  optimum  number  and  size  of 
the  lockable  data  units  in  the  database.  The  authors  con¬ 
cluded  that  the  units  of  locking  should  be  very  small. 
However,  that  conclusion  was  not  based  on  a  fixed  applica¬ 
tion  environment.  Instead,  the  sizes  of  the  transaction 
were  made  smaller  as  the  sizes  of  the  locks  were  reduced. 
Thus  whether  the  observed  increase  in  parallelism  was  due 
to  the  smaller  transactions  or  the  smaller  locks  is 
unclear.  Two  other  problems  with  that  study  were  that 
only  the  CPU  utilization  was  considered  and  that  the  CPU 
resources  of  their  model  were  effectively  considered 
in  f in i te  . 

In  Chapter  2,  a  simulation  model  is  used  to  further 
study  locking  granularity,  optimum  lock  duration  and  a 
variety  of  other  factors. 

3.2.  Distributed  Databases 

Recently,  considerable  attention  has  been  devoted  to 
the  development  ard  use  of  distributed  databases  [LBL76, 
LRL77  ,  LRL731.  In  su^h  an  environment,  the  data  is  dis¬ 
tributed  across  a  network  of  computer  systems.  The  poten- 
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tial  benefits  of  such  d  1  st  r  i  but  i  or-  include  sharing  of  data 
across  different  computer  sites,  increased  parallelism  ir 
accessing  the  database,  locatir-g  data  closer  to  users  and 
increased  reliability. 


However,  one  of  the  major  problems  with  a  distributed 
database  is  the  development  of  a  concurrency  cortrol 
scheme  to  insure  database  consistency  during  multiple  user 
updates  [STON77].  Concurrency  cortrol  schemes  for  a  cen¬ 
tralized  database  do  rot  always  extend  to  a  distributed 
database  . 

For  example,  in  a  centralized  database,  a  transaction 
can  request  all  of  its  locks  at  the  beginning  of  its  pro¬ 
cessing  and  release  them  at  the  end  [CHAM?1*].  In  this 
scenario,  the  locks  are  acquired  ir  one  atomic  action.  If 
one  lock  is  denied,  all  locks  are  denied  ard  the  entire 
lock  acquisition  step  is  repeated.  Note  that  in  this 
scenario,  deadlock  is  impossible. 


In  a  distributed  database,  however,  locks  may  have  to 
be  obtained  at  distinct  computer  sites.  Even  though  the 
lock  acquisition  at  each  site  is  atomic,  deadlock  can 
still  occur  because  ore  processing  unit  does  rot  access 
the  entire  database.  Cor currerc y  cortrol  con sider at i or s 
require  that  the  different  processing  units  communicate 
with  each  other.  The  communication  must  be  used  either  to 
centralize  the  concurrency  cortrol  functions  or  to  prevent 


sa 
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or  detect  a  decentralized  deadlock. 


Several  solutions  to  the  concurrency  cortrol  problems 
for  distributed  databases  have  beer  proposed  [BERN77, 
ROSE77,  GRAY78,  MENA73  and  STON78].  To  evaluate  the  per¬ 
formance  of  the  different  proposals,  the  number  of  mes¬ 
sages  which  must  be  sent  for  concurrency  control  are 
counted.  In  [BERN77]  it  is  shown  that  if  the  tr an sactior s 
are  known  in  advance  (i.e.  only  certain  known.  types  of 
transactions  access  the  database),  different  types  of  con¬ 
currency  cortrol  can  be  used  for  different  types  of  tran¬ 
sactions  and  thereby  further  reduce  the  network  con¬ 
currency  cortrol  traffic. 

Unfortunately,  a  count  of  overhead  message  traffic 
does  not,  by  itself,  determine  the  effects  of  the  con¬ 
currency  control  on  the  overall  performance  of  the  distri¬ 
buted  database  system.  Other  factors  such  as  overall  sys¬ 
tem  load,  the  amount  of  non-local  processing,  and  the 
scheduling  of  transactions  must  also  be  considered. 

In  Chapter  3,  a  simulation  model  is  used  to  examine 
the  effects  of  these  factors  as  well  as  the  effects  of  the 
message  traffic. 

In  a  distributed  database,  the  same  data  may  be 
stored  at  several  computer  sites.  These  multiple  copies 
create  additional  concurrency  control  problems  in.  that  the 
copies  must  be  kept  mutually  consistent  during  multiple 
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updates.  (The  simulations  i r  chanter  7  do  rot  explicitly 
model  the  multiple  conv  update  scenarios.  However,  some 
of  the  results  of  the  study  car  be  applied  to  the  multiple 
copy  update  problems.) 

Other  studies  do  directly  model  the  multiple  copy 
update  problems  but  do  rot  address  the  internal  database 
consistency  issues.  In  [GRAP7B1,  different  algorithms  for 
multiple  copy  cor  sistercy  are  analysed  in  terms  of  the 
performance  of  a  distributed  database  management  system. 
In  [GARC78],  a  simulation  model  is  used  to  compare  the 
effects  of  two  algorithms  [ALSB7&,  TH0M7S1  or  the  overall 
performance  of  the  distributed  database  system.  Both  stu¬ 
dies  show  that  under  a  wide  variety  of  assumptions  a  "pri¬ 
mary  copy  model"  is  better  for  maintaining  multiple  copy 
consistency.  The  primary  site  model  basically  implies 
that  the  control  of  updates  to  the  different  copies  is 
channelled  through  a  single  or  primary  copy  of  the  data¬ 
base. 

n .  OVERVIEW 

This  thesis  will  analyze  the  effects  of  concurrency 
control  or  the  performance  of  both  centralized  and  distri¬ 
buted  databases.  In.  both  cases,  simulatior  models  are 
used  to  study  the  tradeoffs  between  increased  parallelism 
and  increased  locking  overhead. 
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One  parameter  of  primary  interest  is  the  locking 
granularity.  Locking  granularity  refers  to  the  size  of  a 
lockable  unit  or  granule  which  covers  a  portion  of  the 
database.  Locking  granularity  car.  be  extremely  fine  (i.e. 
one  lock  is  associated  with  each  sector  of  a  disk).  Or, 
locking  granularity  could  be  extremely  coarse  (i.e.  one 
lock  is  associated  with  each  disk  drive). 

In  Chapter  2 ,  ar,  extensive  simulation,  model  is 
presented  which  explores  a  large  class  of  concurrency  con¬ 
trol  alternatives.  The  model  is  par ameter i zed  to  provide 
insights  into  the  locking  parameters  for  a  wide  variety  of 
database  systems.  The  simulation  experiments  study  lock¬ 
ing  granularity,  the  overhead  costs  of  locking,  the  tran¬ 
saction  types  and  sizes,  a  locking  hierarchy,  and  the 
times  when  locks  are  acquired.  Most  of  these  results  have 
been  published  previously  [RIES77,  RIES791. 

In  Chapter  3,  the  simulation  models  are  extended  to 
distributed  database  systems.  These  experiments  study  the 
effects  or:  performance  of  locking  granularity,  four  dis¬ 
tributed  concurrency  control  algorithms,  the  transaction 
types  ard  sizes,  and  various  network  related  parameters. 

In  Chapter  '1,  the  major  results  these  studies  are 
summarized  and  several  directions  for  future  research  are 


suggested . 


CHAPTER  2 


CENTRALIZED  DATABASE  SYSTEMS 


1-  INTRODUCTION 

In  order  to  insure  the  consistency  conditions  dis¬ 
cussed  in.  chapter  1,  a  variety  of  concurrency  control 
mechanisms  [ CHAM7^ ,  C0DA71 ,  ESWA76 ,  GRAY75,  GRAY76 , 
MACR76,  STEA76,  ST0N7N  ]  have  been  proposed  and  implemented 
in  single  machine  database  management  systems.  In  this 
chapter  the  performance  issues  of  these  types  of  mechan¬ 
isms  are  examined. 

Clearly  there  are  advantages  to  increasing  the  paral¬ 
lelism  in  processing  transactions.  Unfortunately,  the 
price  of  this  increased  parallelism  is  the  increased  over¬ 
head  which  must  be  expended  to  achieve  it.  The  goal  of 
this  chapter  is  to  study  the  tradeoff  between  these  con¬ 
flicting  performance  considerations  on  a  single  machine 
database  management  system. 

In  section.  2,  a  simulation  model  is  developed  to 
study  that  tradeoff.  In  sectior  3,  the  results  of  experi¬ 
ments  with  that  simulation  model  are  reported.  In  addi¬ 
tion,  two  extensions  to  that 


model  are  used  to  study 


1‘> 


alternate  i-or.c  urrertv  cor  trol  mechar  i  sms  .  Fir  ally,  the 
major  corclusicr  s  are  summarized  in  section  !J  .  Ir.  the 
remainder  of  this  section  ,  the  performance  issues  ar.d 
approaches  of  centralize!  corcurrerc y  cor trol  are 
rev  iewed . 

1.1.  Per  former ce  Issues 

An  evaluation  of  concurrency  control  must  include  an 
analysis  of  the  tradeoffs  between  the  overhead  spent  or. 
locking  versus  the  advantages  of  allowing  more  parallel 
access  to  the  database.  The  advantages  of  increased 
parallelisms  are  in  terms  of  better  user  resoor.se  time  and 
increased  machine  ut i 1 i za t ion . 

The  amount  of  overhead  spent  or:  locking  is  deoerder.t 
on  several  parameters  of  the  concurrency  control  mechan¬ 
ism.  These  parameters  include  the  size  of  a  lockable 
unit,  the  costs  of  setting  and  releasing  locks,  the  pro¬ 
portion  of  resources  required  for  locking  and  the  length 
of  time  for  which  the  locks  are  held.  Each  of  these 
parameters  is  considered  in  turn. 
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1.1.1.  Loc  k i r  g  Granularity 


All  of  the  corcurreri  v  cor  trol  mechanisms  involve  the 
locking  of  some  physical  or  logical  portior  of  the  data¬ 
base.  The  smallest  portior  of  the  database  which  can  be 
locked  is  referred  to  as  a  "granule".  The  size  of  a 
granule  varies  in.  different  database  management  systems. 
In  some  systems  (CODASYL  [CQDA731,  System  R  [ ASTR76  ]  , 
DMS-1100  [GRAY7S])  the  granule  may  be  as  small  as  ore 
record.  Other  systems  (Svstem  2000  [SPIT76],  IMAGE 

[HEWL771)  support  one  granule  covering  the  entire  data¬ 
base.  Still  other  systems  (DBMS-11  [ DEC77  ]  ,  LSL  [LIPS76]) 
support  intermediate  sized  granules  such  as  files  or 
areas . 

There  is  a  clear  tradeoff  between  locking  overhead 

**  .. 

and  parallelism  based  on  the  locking  granularity.  Fine 
granularity  allows  a  higher  degree  of  parallelism  at 
greater  cost  in  managing  locks.  For  example,  assume  that 
a  granule  corresoords  to  a  reccrhd  in  a  database.  Then  the 
transactions  may  run  in  parallel  without  corflict  as  lorg 
as  they  access  distinct  records.  However,  the  database 
system  must  be  prepared  to  handle  as  many  locks  as  there 
are  records  in  the  database. 

Coarse  granularity,  on  the  other  hand,  inhibits 
parallelism  but  minimizes  management  of  locks.  If  the 
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granule  is  ti.r  siiere  I  the  er.  tir<>  database  ,  r  trar  cat.  tier  r. 
will  cur  in  parallel  .  The  dnt.  »ha  sy  si  k^epr  tr  ru  k  of 
only  ore  1  oek  . 

Different  sized  granules  can  he  sue nor  Led  ir  a  look 
hierarchy  [GRAY76J.  Ir.  a  lock  hierarchy,  a  tree  structure 
of  locks  is  supported.  A  transaction  car.  either-  expli¬ 
citly  hold  leeks  on  lower  branches  of  the  tree,  or  impli¬ 
citly  hold  those  locks  by  explicitly  locking  an  ancestor 
node  common  to  all  of  the  lower  branches. 

With  such  a  hierarchy,  the  costs  of  locking  for  large 
trar.  sac  tior  s  may  be  greatly  reduced  since  it  is  cheaper  to 
set  one  large  look  than  to  set  many  small  locks.  However, 
the  locking  costs  for  the  trar  sac  ti  or.  s  using  small  locks 
may  increase.  Those  transactions  would  have  to  set  all 
the  locks  in.  the  path  from  the  leaves  to  the  root  of  the 
tree.  Again  a  tradeoff  is  observed  between  the  parallel¬ 
ism  allowed  and  the  locking  overhead. 

For  example,  consider  a  two-level  hierarchy  where  one 
loc  k  at  the  top  level  cortrols  access  to  the  or  tire  data¬ 
base  and  many  (more  than  ore)  locks  at  the  lower  level 
control  access  to  individual  "parts"  of  the  database.  A 
transaction  which  accesses  the  entire  database  car 
exclusively  lock  the  one  top  level  lock.  Without  a  lock 
hierarchy  and  just  the  small  locks,  it  would  be  much  more 
expensive  for  that  transaction  to  lock  all  of  the  small 


locks  . 


The  above  lock  hierarchy,  however,  increases  the 
locking  overhead  for  the  transaction  which  just  access  ore 
"part"  of  the  database.  That  transaction  must  set  the 
higher-level  lock  in  an  "intention"  mode  [GRAY76]  (imply¬ 
ing  that  explicit  locking  is  required  at  the  lower  level) 
and  still  lock  the  individual  part  of  the  database.  Thus, 
that  transaction  sets  two  locks.  Without  a  lock  hierarchy 
and  just  the  small  lock,  that  transaction  would  set  only 
one  lock. 

h  1.2. 

Concurrency  control  overhead  refers  to  the  amount  of 


computer 

resources 

utilized  by 

the 

locking 

mechan i sm . 

This  "overhead"  can 

be 

thought 

o  f 

as  the 

dif ference 

between 

the  resources 

required 

by 

a  transaction  in  a 

multi-user  system  and  the  resources  that  would  be  required 
if  the  transaction,  could  be  run  as  the  only  user  of  the 
database.  The  locking  mechanisms  must  comoete  with  the 
transactions  for  memory,  CPU  cycles,  and  I/O  channels. 
Thus,  as  a  locking  mechanism  increases  in  complexity  and 
requires  more  resources,  it  will  start  to  interfere  with 
the  running  of  the  transactions. 


The  ratio  of  resources  spent  for  locking  to  resources 
spent  for  processing  transactions  is  critical.  For  exam¬ 
ple,  a  ratio  of  one  implies  that  it  is  as  expensive  to 
lock  a  granule  as  it  is  to  process  the  data  in  that 
granule.  In  this  case,  two  transactions  could  have  been 
run  without  locking  in  the  time  it  takes  a  transaction  to 
set  its  locks,  process  the  data,  and  release  the  locks.  A 
less  expensive  concurrency  control  which  only  allowed  half 
of  the  parallelism  might  provide  the  same  throughput . 

2-1.3.  Lock  Duration 

Another  factor  which  affects  the  degree  of  parallel¬ 
ism  and  the  cost  of  concurrency  control  is  the  time  period 
for  which  the  locks  are  held.  Two  simple  procedures  which 
insure  that  a  transaction  is  two-phased  (See  Chapter  1) 

are : 

1)  set  all  locks  at  the  beginning  of  a  transaction  or 

2)  hold  all  the  locks  until  the  end  of  a  transactior  . 

If  the  secord  option  is  chosen,  the  locks  can  still 
be  preclaimed  as  in  option  1  or  requested  and  granted  as 
needed  by  the  transaction. 

A  performance  tradeoff  is  again  possible.  By  not 
locking  resources  until  they  are  required,  additional 


parallelism  is  possible.  However,  the  locking  overhead 
costs  are  increased  by  two  factors.  First,  the  con¬ 
currency  control  mechanism  must  check  for  deadlock 
[C0FF71].  Second,  if  deadlock  is  detected,  a  transaction, 
may  have  to  be  restarted.  The  resources  already  used  by  a 
restarted  transaction  should  also  be  included  as  overhead 
costs  since  they  would  not  have  been  used  if  the  transac¬ 
tion  was  run  by  itself. 

In  summary,  the  important  performance  parameters  are 
locking  granularity,  locking  overhead,  and  lock  duration. 

1_.2.  Locking  !^e_cl2£!li sms 

Two  general  options  have  been  proposed  for  single 
machine  concurrency  control  --  physical  locks  and  predi¬ 
cate  locks. 

1 .2 . 1 .  Physical  Locks 

Physical  locks  are  placed  or  records,  pages,  seg¬ 
ments,  files,  areas  or  the  entire  database.  Ir.  this  case, 
a  "granule"  refers  to  a  physical  portion  of  the  database. 

With  physical  locks,  a  data  manipulation  command  can¬ 
not  proceed  if  a  granule  it  needs  is  locked  by  someone 
else.  Various  strategies  for  requesting  and  releasing 


locks  have  beer:  suggested  [CilAHT'l,  GRAY76,  STEA76, 
MACR76].  Some  of  these  strategies  require  the  detection 
resolution  of  deadlock. 

The  basic  idea  behind  physical  locking;  is  straight 
forward.  If  a  transaction  needs  to  read  a  portion  of  the 
database  but  not  write  it,  a  read  or  shared  lock  must 
first  be  obtained  on  a  granule  which  physically  covers 
that  portion  of  the  database.  Other  transactions  which 
also  read  that  portion  or  a  portion  covered  by  the  same 
granule  can  share  that  lock. 

If  all  or  a  portion  of  the  granule  is  to  be  updated, 
an  exclusive  lock  must  be  obtained  which  cannot  be  shared 
by  other  running  transactions.  The  two-phase  requirement 
insists  that  no  locks  can.  be  released  until  the  transac¬ 
tion  has  acquired  all  of  the  locks  that  it  needs. 

1.2.?.  Predicate  Locks 

A  predicate  lock  can  be  set  or.  the  exact  portion  of 
the  database  which  is  to  be  accessed.  The  portion  of  the 
database  which  is  locked  is  determined  by  predicates  or 
qualifications  associated  with  the  tr an saction  .  The 
predicate  (i.e,  "all  records  with  date  field  values  in 
June,  1976")  restricts  the  transaction  to  a  logical  subset 
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of  the  database.  Such  locks  do  not  necessarily  correspond 
to  ary  physical  portion  of  the  database.  This  approach  is 
explored  in  [FLOim,  STONT'l  ,  ESWA76]. 

In  predicate  locking,  a  predicate  correspond ing  to  a 
selection  criteria  of  a  transaction  is  submitted  to  the 
locking  mechanism.  If  the  locking  mechanism  can  "prove" 
that  a  transaction  does  not  conflict  with  any  running 
transactions,  the  locks  are  granted.  Otherwise,  the 
requesting  transaction,  must  wait.  A  propositional  logic 
"theorem  prover"  can  be  used  to  prove  that  two  transac¬ 
tions  do  not  conflict.  The  sophistication  of  the  theorem 
prover  can  be  varied  depending  on  the  tradeoff  between 
increased  parallelism  and  CPU  recourses  used  for  locking. 

The  granularity  in.  predicate  locking  also  varies. 
For  example,  a  predicate  such  as  "employee_ro= 1 23^ "  might 
restrict  the  transaction  to  one  record.  On  the  other 
hand,  a  predicate  such  as  "depar tmer t= ergin eer ing"  might 
represent  hundreds  of  records.  Notice  that  predicate 
locks,  like  physical  locks,  can  be  acquired  throughout  the 
duration  of  a  transaction. 

Predicate  locking  has  two  obvious  advantages.  One  is 
that  a  predicate  lock  can  accurately  describe  the  exact 
logical  portion  of  the  database  that  is  to  be  accessed  by 
a  transaction.  The  second  is  that  the  cost  of  setting 


such  a  lock  depends  on  the  number  of  simultaneous  transac¬ 
tions  actually  submitted  and  not  or  the  amount  of  data 
that  is  actually  accessed. 

However,  the  predicate  locking  mechanism  may  need¬ 
lessly  keep  a  transaction  from  running.  Suppose  the 
predicate  "AGE>29"  has  been  granted  a  lock  for  a  running 
transaction  and  that  another  transaction  issues  the 
request  "AGE<31".  If  no  one  with  AGE=30  were  in  the  data¬ 
base,  both  transactions  could  be  allowed  to  run.  But  the 
predicate  locking  mechanism  would  require  that  the  second 
transaction  waits. 

Thus,  predicate  locking  may  reduce  corcurrercy  con¬ 
trol  overhead  at  the  expense  of  allowing  less  parallelism 
in  accessing  the  database. 

2.  model  description 

A  simulation  model  is  used  to  investigate  the  tra¬ 
deoffs  between  concurrency  control  overhead  and  increased 
parallelism.  The  model  is  described  by  first  explaining 
the  flow  of  transactions  around  a  closed-loop  model.  Next 
the  model  input  and  output  parameters  are  discussed. 
Finally,  the  allocation  and  competition  for  resources  in 
the  model  are  described. 


2.  K  Transaction  Fl^ow 

The  running  of  transactions  against  a  database  is 
simulated  by  assuming  there  are  a  fixed  number  of  transac¬ 
tions  which  are  cycled  continuously  for  TMAX  time  units 
around  the  model  shown  in  figure  2-1.  A  transaction  goes 
through  the  following  steps: 

1)  Arrive  on  the  pending  queue 

2)  Acquire  locks 

3)  Process  I/O  requests 

4)  Process  CPU  requests 

5)  Release  locks 

6)  Generate  a  new  transaction  and  return  to  step  1 

These  steps  are  explained  in  more  detail  below. 

Initially,  the  transactions  arrive  ore  time  unit 
apart  and  are  placed  on  the  pending  queue.  The  transac¬ 
tion  is  removed  from  the  PENDING  queue  and  all  required 
locks  are  requested.  If  the  locks  are  granted,  the  tran¬ 
saction  is  nlaced  or.  the  bottom  of  the  I/O  queue.  If  the 
locks  are  denied,  the  transaction  is  placed  on  the  bottom 
of  a  RLOCKED  queue.  The  blocking  transaction  is  recorded. 
(The  description  of  which  locks  are  required  by  a 


transaction  is  giver  in  section  2.3.)  Note  that  no  locks 
are  held  while  or  the  blocked  queue  so  deadlock  is  impos¬ 
sible. 

After  completing  the  I/O  required,  the  tran sactior:  is 
placed  or  the  bottom  of  the  CPU  queue. 

After  completing  the  CPU  required,  the  transaction 
releases  its  locks.  At  this  point  a  new  transaction  is 
added  to  the  end  of  the  PENDING  queue.  (Note  that  each 
transaction  goes  through  one  I/O  phase  and  one  CPU  phase. 
Although  they  are  sequential  in.  the  model,  the  result 
would  be  the  same  if  each  transaction  were  to  go  through 
many  I/O  -  CPU  phases  in  a  single  cycle.)  All  transactions 
that  were  blocked  by  the  completed  transaction  are  placed 
on  the  front  of  the  PENDING  queue. 

2.2.  Model  Parameters 

The  input  parameters  can  be  divided  into  those  that 
characterize  the  workload  ,  and  those  that  characterize  the 
system.  Workload  Darameters  describe  the  database  and  the 
transactions  that  are  run  against  that  database.  System 
parameters  describe  the  computer  system  and/or  the  data¬ 
base  management  system  characteristics.  The  output  param¬ 
eters  char ac ter  i  ze  the  throughput,  overhead  and  utiliza¬ 
tion  of  the  system.  These  parameters  are  all  described  in 
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more  detail  below. 


2.2.1.  Workload  Parameters 

The  workload  input  parameters  are  summarized  in  Table 
2-1.  The  number  of  transactions ,  NTRAN,  in  the  system  is 
fixed.  The  closed  loop  model  could  have  two  interpreta¬ 
tions.  As  each  transaction  completes,  the  user  submits 
another  transaction .  Alternately,  the  transactions  could 
be  viewed  as  application  programs.  When  one  of  these  com¬ 
pletes,  another  application  program  enters  the  system  to 
take  its  place. 

The  database  size,  DBSIZE,  refers  to  the  number  of 
entities  in  the  database.  In  this  model,  the  database  is 
an  abstract  collection  of  entities.  An  entity  can  be 


Table  2-1  Workload  Parameters 


Parameter 


Description 


NTRAN 

DBSIZE 

RAD 

AMEAN 

BMEAN 


ALPH 

LKPLMT 


number  of  transactions 
number  of  entities  in  the  database 
a  transaction  size  parameter, 
mean  for  exponential  distribution 
of  transaction  size. 

another  mean  for  exponential  distribution 

of  transaction  size.  Used  with  AMEAN  for 

hyper-ex  do  nential  distribution 

of  transaction  sizes. 

cut  of  proportion  between  AMEAN 

and  BMEAN. 

lock  placement  assumption  (see  below) 
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thought  of  as  the  unit  of  data  moved  by  the  operating  sys¬ 
tem  into  the  database  system  buffers. 

In  the  simulation,  three  types  of  distributions  for 
transaction  sizes  are  used.  The  size  of  a  transaction 
refers  to  the  number  of  entities,  ME,  touched  or  accessed 
by  a  p,iven  transaction.  The  number  of  entities  "touched" 
or  accessed  by  a  Riven  transaction  completely  determines 
the  amount  of  I/O,  CPU  and  lock  resources  required  by  that 
transaction.  In.  the  simplest  case,  the  sizes  of  the  tran¬ 
sactions  are  uniformly  distributed  by  the  RAD  parameter. 

i.  u 

The  number  of  entities  touched  by  the  1  transaction  is 
Riven  by: 


NEi  =  i*RAD,  forisl . NTRAN 

This  distribution  reflects  a  workload  with  a  uniform  mix 
of  different  sized  transactions. 

The  second  distribution  of  transaction  sizes  is 
exponential.  The  average  transaction  size  is  determined 
by  the  AMFAN  parameter.  In  this  case, 

NE^=-AMF.AN*loR(rrd) 

where  rnd  is  a  uniformly  distributed  random  number  between 
zero  and  ore.  This  distribution  reflects  a  workload  where 


most  of  the  transactions  are  small  a  very  few  transactions 
are  1  a  r  r  e  . 


The  final  distributior  used  is  hyper-ox  do re r-ti a  1  with 


three  parameters,  A  FT  A  N  ,  RHEAN,  or  d  ALPH.  Ir:  this  distri¬ 
butior,  some  (ALPH  x  100  percent)  of  the  transactiors  have 
sizes  which  are  exponentially  distributed  with  a  sear  of 
OMF.AN.  The  other  transactions-  have  sizes  which  are 
exponentially  distributed  with  mean  AMEAM.  In  this  case, 

NEi=-BMEAN*lorT(rnd1  ) 

if  rnd2  <  ALPH  or 


NE^=-AMEAN*log(rnd1  ) 

if  r rd2  >=  ALPH 

where  rndl,  and  rrd2  are  independent  random  varia;les 
similar  to  rrd .  This  distribution  is  used  to  model 
scenarios  where,  for  instance,  most  of  the  transactions 
are  extremely  small  and  only  touch  a  few  records  or  cages 
of  a  database,  while  a  few  transactions  must  access  a  very 
large  number  of  records.  Note  that  the  exponential  dis¬ 
tribution  is  just  a  special  case  of  the  hyper- ex por er t i a  1 
distributior  with  an  ALPH  of  zero. 

The  lock  placement  parameter,  LKPL^t,  determines  the 
number  of  locks  that  a  giver:  transaction  requires.  Three 
different  assumptions  regarding  lock  placement  are  simu¬ 


lated  . 


With  "well  placed"  locks  (LKPLMT  =  1),  the  number  of 
locks  required  by  a  giver  trarsactior  is  exactly  propor¬ 
tional  to  the  percentage  of  the  database  touched  or 
accessed  by  the  transaction.  For  transaction  i,  the 
number  of  locks,  NL,  is 

NL.=CEILING(MEi*MGRAN/DBSI?.E) 

where  NGRAN  is  the  total  number  of  locks  available. 
Hence,  a  transaction  which  touched  half  of  the  entities  in 
the  database  would  require  half  of  the  possible  database 
locks.  Note  that  this  amounts  to  assuming  that  the 
granules  are  "well  placed",  i.e.  that  the  entities  needed 
by  the  transactions  are  packed  into  as  few  'lockable' 
granules  as  possible.  This  assumption  is  reasonable  for 
transactions  which  access  the  database  sequentially. 
Although  sequential  processing  in  database  applications 
has  been  observed  [RODR76],  actual  transactions  may 
require  a  combination  of  sequential  and  random  accesses  to 
the  database. 

Under  a  "worst  case  placement"  assumptior  (LKPLMT  = 
2),  each  trarsactior  requires  the  maximum  number  of 
granules  possible.  In  this  case 

NL.=MIN(NE.  NGRAN). 

1  1  » 
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If  the  total  number  of  entities  touched  by  n  giver  trar.- 
sactior  ,  NR,  is  greater  than  the  number  of  looks  cover  in  r, 
the  entire  database,  NGRAN,  then  in  the  worst  case,  all  of 
the  locks  might  have  to  be  acquired  in  order  to  access  the 
needed  entities.  If  NE  is  less  than  NGRAN,  the  number  of 
locks  that  have  to  be  set  is  bounded  by  the  number  of 
entities,  NE .  Thus,  the  number  of  locks  required  is  the 
minimum  of  the  number  of  locks  for  the  entire  database  and 
the  number  of  entities  touched  by  the  transaction.  This 
assumption  simulates  an  " unc coper at i veM  transaction  ,  i.e. 
one  whose  access  pattern  is  the  worst  possible  from  the 
lock  mechanism  point  of  view.  This  scenario  is  the  oppo¬ 
site  extreme  of  the  "well  placed"  assumption. 

Under  a  "random  access  placement"  assumption,  a 
mean-valued  formula  is  used  to  estimate  the  number  of 
locks  required  for  each  transaction.  The  number  of  locks 
required  under  this  assumption  is  analogous  to  the  number 
of  blocks  accessed  when  randomly  selecting  records  from  a 
blocked  file.  The  formula  for  this  number  and  its  deriva¬ 
tion  are  given  in  [YA0771.  This  model  accurately  reflects 
random  processing  where  the  probability  of  accessing  arv 
entity  is  the  same  and  independent  of  any  previous  enti¬ 
ties  accessed.  Let  DRSIZE  be  the  number  of  entities  in 
the  database,  NGRAN  be  the  total  number  of  locks,  and  p  be 
the  number  of  entities  per  lock  (  =  DBS  1 7.  E/NG  R  A  N  )  .  Then  a 
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transaction  which  accesses  NE  entities  requires 


NCR AM  * 


1  - 


rDRSIZE-p 

Se 

"DRS I Z  E 
CNE 


T,  .  -DBSIZE-p  .  „DBS  I Z  E 

The  expressions  C^p  and  represent 


locks 

the  number  of  different  ways  ME  entities  can  be  selected 
from  DBSIZE-p  and  DBSIZE  entities  respectively.  The 
derivation  of  this  formula  is  identical  to  the  derivation 
in  [YA077]  and  is  not  repeated  here. 


2.2.2.  System  Parameters 

The  system  parameters  are  listed  in  Table  2-2.  The 
number  of  granules,  NGRAN,  into  which  the  database  is 
divided  is  varied  from  one  to  the  number  of  entities  in 
the  database,  DBSIZE.  A  granule  is  the  unit  which  is 
locked  by  a  transaction.  Each  granule  is  assumed  to  be 
the  same  size.  Hence,  if  NGRAN  =  1,  a  granule  is  the 
entire  database  of  DBSIZE  entities.  If  NGRAN  =  2,  a 
granule  is  DBSIZE/2  entities.  If  NGRAN  -  DBSIZE,  each 
granule  is  1  entity. 


The  CPU  costs  for  processing  a  transaction  are  deter¬ 
mined  by  the  CPURATE  parameter.  The  CPURATE  refers  to  the 
CPU  resources  required  for  processirg  ore  entity  of  the 
database  where  CPU  resources  are  in  time  units  of  the 


i  hi  rfiatfri  «' i*li— 


Table  2-2  System  Parameters 


Parameter 


Description 


NCRAN 

CPURATE 

10 RATE 

LCPURATE 

LIORATE 

IOOVLP 


number  of  lockable  granules 
CPU  time  to  process  ore  entity 
I/O  time  to  process  ore  entity 
CPU  rate  to  process  one  lock 
I/O  rate  to  process  ore  lock 
number  of  simultaneous  I/O 
operations  permitted 


simulation.  Note  that  these  are  the  resources 


for  pro¬ 


cessing  the  transactions  and  do  rot  include  any  costs  for 


processing  the  locks. 


Similarly,  the  I/O  costs  for  processing  a  transaction 
are  determined  by  the  IORATE  oarameter.  Note  that  the 
CPURATE  and  IORATE  could  have  also  been,  considered  as 
workload  parameters  because  in  many  cases  they  are  appli¬ 
cation  dependent  [HAWT79]. 


The  lock  CPU  parameter,  LCPURATE,  refers  to  the  CPU 
resources  required  to  request  (and  set/release)  a  lock  for 
one  granule. 


Similarly,  LIORATE  determines  the  I/O  overhead  for 
setting  one  lock.  For  some  DhMS  systems,  lock  tables  are 
kept  entirely  ir:  main  memory.  These  systems  are  modeled 
by  a  LIORATE  of  zero.  On  the  other  hard,  a  database  sys¬ 
tem  which  has  as  many  locks  as  pages  in  the  database,  may 
have  to  keep  lock  tables  or  secondary  storage  devices. 
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Such  systems  would  have  a  nor-zero  LIORATE  parameter. 

The  I/O  overlap,  IOOVLP,  indicates  how  many  simul¬ 
taneous  I/O  operations  are  possible.  This  parameter  is  a 
surrogate  for  the  number  of  independent  paths  used  between 
main  memory  and  secondary  storage  (and  hence  for  how  much 
I/O  activity  can  go  on  in  parallel). 

2.2.3.  Output  Parameters 

The  performance  measurements  shown  in  Table  2-3  are 
generated  by  each  simulation  run.  The  total  CPU  time, 
TCPU,  refers  to  the  number  of  time  units  in  which  the  CPU 
is  busy.  During  TMAX  -  TCPU  time  units  the  CPU  is  idle. 


The  total  I/O  units,  TIO,  is  the  number  of  time  units 
in  which  the  I/O  resources  are  busy.  The  total  I/O  units 
utilized  can  become  larger  than  TMAX  if  the  I/O  overlap 


Table  2-3  Output  Parameters 


Parameter  Description 


TCPU 

TIO 

LOCKCPU 
LOCKIO 
USEFULC  P(J 
USEFUL  10 
TRANCOM 
AVERRES 


Total  time  CPU  active 
Total  time  I/O  active 
CPU  overhead  for  locking 
I/O  overhead  for  locking 
CPU  time  for  transactions 
I/O  time  for  tr an  sac ti or s 
number  of  transactions  completed 
average  response  time 
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parameter  is  greater  than  1.  In  fact  TIO  is  bounded  above 
by  TM AX  *  IOOVLP . 

The  CPU  units  used  for  lock  management  are  recorded 
in  LOCKCPU  while  the  I/O  units  used  for  locking  are 
recorded  in  LOCKIO. 

The  useful  computer  utilization,  USEFULCPU  and  USEFU- 
LIO,  refer  to  the  net  resources  used  for  transaction  pro¬ 
cessing.  These  measurements  reflect  the  transaction  pro¬ 
cessing  time  without  the  concurrency  control  overhead. 
Note  that 

TCPUrLOCKCPU+USEFULCPU 

TIO=LOCKIO+LOCKCPU . 

The  total  number  of  transactions  completed  at  the  end 
of  a  simulation  run,  TRANCOM,  and  the  average  response 
time,  AVERRES,  are  also  recorded.  The  time  when  each 
transaction  is  first  placed  or  the  pending  queue  is  con¬ 
sidered  an  arrival  time  for  that  transaction.  The  differ¬ 
ence  between  that  time  and  the  time  when  that  transaction 
releases  its  locks  is  called  the  response  time.  Some 
transactions  may  have  started  but  not  finished  at  the  com¬ 
pletion  of  the  simulation,  run.  These  transactions  are  not 


included  in  the  computation  of  TRANCOM  or  AVERRES. 


2.3.  Resource  Allocation  an  d  Usar,e 

The  above  parameters  completely  determine  the 
resources  required  by  each  transaction.  These  resources 
are  summarized  in  Table  2-4. 


The  CPUTIME  represents  the  total  number  of  time  units 
that  a  transaction  would  be  on  the  CPU  queue  if  it  were 
running  by  itself.  However,  if  there  are  N  transactions 
on  the  CPU  queue,  the  CPU  is  multiplexed  amort*  those  N 
transactions.  For  example,  if  there  are  always  2  transac¬ 
tions  on  the  CPU  queue,  a  transaction  with  a  CPUTIME  =  50, 
would  remain  on.  the  CPU  queue  for  100  time  intervals. 


The  IOTIME  is  similar,  except  for  the  effect  of  the 
IOOVLP  parameter .  If  there  are  N  transactions  on.  the  I/O 
queue,  each  transaction.  progresses  min.  (  1  , 100VLP/N  )  time 

Table  2-4  A  Transaction 


RESOURCE 


FORMULA 


NE 

NL 

CPUTIME 
IOTIME 
L0CKI0TIME 
LOCKC  PUT  I  ME 


=  furetion(RAP) 

or  function ( AMR  AN  ,  RMEAN  ,  ALPH) 

=  f unction ( NE  ,  LKPLMT,  DBSIZE) 
=  NE  *  CPU  RATE 
=  NE  *  IORATE 
=  NL  «  L I  OR  ATE 
=  NL  *  LC PU R ATE 


units.  The  progress  is  bounded  above  by  1  to  simulate  ore 
transaction  having  only  ore  outstanding  I/O  request  at  a 

time . 


The  locking  mechanisms  are  giver  a  higher  priority 
for  the  I/O  and  CPU  resources  than  the  active  transac¬ 
tions.  Also  rote  that  these  costs  are  repeated  each  time 
a  transaction  requests  its  locks.  For  example,  suppose  a 
transaction  requests  locks,  they  are  denied,  and  the  tran¬ 
saction  is  placed  on  the  blocked  queue.  Later  that  tran¬ 
saction.  is  removed  from  the  blocked  queue,  the  locks  are 
requested  again,  and  this  time  they  are  granted.  The 
total  lock  overhead  associated  with  this  transaction  is 
twice  NE  times  the  lock  rates. 

Two  approaches  are  used  to  simulate  the  competition 
for  the  available  granules.  Under  both  approaches,  the 
decision  to  grant  or  deny  a  lock  request  is  based  on 
another  uniformly  distributed  random  variable,  rrd3. 

Under  one  approach,  the  granules  for  each  transaction, 
are  considered  to  be  completely  uncorrelated.  Let  CRL  be 
the  number  of  locks  currently  held  by  the  active  transac¬ 
tions.  Then  a  transaction  needing  NL  locks,  has  those 


locks  granted  if 
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NGRAN-CRL 

S  LNL 
rrd3  > 

Sl 

The  above  expression  is  simply  the  number  of  ways  of 
choosing  NL  locks  from  those  that  are  already  still 
unclaimed  divided  by  the  number  of  ways  of  chosen  the  NL 
locks  from  all  of  the  locks. 

Under  the  well-placed  lock  assumption,  the  above  for¬ 
mula  actually  penalizes  finer  granularity.  For  example, 
doubling  the  number  of  locks,  (2  *  NGRAN),  could  result  in 
also  doubling  NL  and  CRL.  The  number  of  locks  for  a  tran¬ 
saction,  NL,  would  be  doubled  if  a  transaction  touched  all 
of  the  entities  covered  by  a  given  lock.  But  then,  the 
probability  of  a  successful  lock  request  is  actually 
smaller  due  to  the  finer  granularity  because 

2*NGRAN-2*CRL  NGRAN-CRL 

L2»NE  _ _  _NE__ 

r2*'NGRAN  "  r NGRAN  * 

L2*NE  UNE 

The  right  hand  side  is  the  probability  of  obtaining  NL 
locks  with  the  original  granularity  while  the  left  hand 
term  is  the  same  probability  if  the  number  of  locks  were 
doubl ed . 

To  avoid  this  bias  under  the  well-placed  lock  assumc- 
tion ,  a  second  approach  to  computing  lock  conflicts  is 
used.  With  this  approach  it  is  assumed  that  the  first 
requested  granule  is  uncorrelated  with  any  of  the  granules 


v 


which  are  already  locked.  Fur  therrnore ,  the  additioral 
requested  granules  are  assumed  to  be  distinct  from  the 
already  locked  granules.  Under  this  assumption,  the  locks 
are  granted  if 


rnd3 


_  CRL__ 

(NGRAN-NK+TT ' 


Under  either  approach,  if  the  locks  are  granted,  CRL 
is  incremented  by  NL.  If  the  locks  are  denied,  one  of  the 
active  transactions  is  picked  as  the  blocking  transaction. 
The  probability  that  a  transaction ,  say  Tj  is  the  blocking 
transaction  is  NL./CRL;  i.e.  is  directly  proportional  to 
the  number  of  locks  held  by  the  blocking  transaction. 


3.  RESULTS  and  DISCUSSION 

In  this  section  the  results  of  running  the  simulation 
under  a  wide  variety  of  parameter  settings  are  reported. 
First,  the  results  of  some  initial  runs  of  the  simulation 
are  explained.  Next  the  effects  of  varying  the  workload 
and  system  parameters  are  reported.  Finally,  the  effects 
of  two  changes  to  the  basic  simulation  model  are 


described. 
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3.K  An  Initial  Scenario 

The  simulation  is  initially  run  with  the  workload 
parameters  shown  in  Table  2-5  for  10,000  (TMAX)  time 
units.  The  system  parameters  for  the  first  run  are  shown 
in  Table  2-6. 

In  this  scenario,  ten  transactions  were  submitted  to 
a  database  of  5000  entities.  The  transactions  required 
from  50  to  500  entities  each  (initially  the  sizes  were 
uniformly  distributed).  (The  simulation  was  also  run  with 
up  to  20  transactions  with  no  appreciable  effect  other 
than  scale  on  the  output  parameters.) 


Table  2-5  Sample  Workload  Parameters 

Parameter  Value 

NTRAN  10 

DBSIZE  5000 

LKPLMT  Well-Placed 

RAD  50 


Table  2-6  Sample  System  Parameters 
Parameter  Value 


NCR  AN 

C  PU  RATE 

IORATE 

LCPIJRATF. 

LIORATE 

IOOVLP 


1  to  5000 
.05 
.20 
.01 
.20 
1 


The  locks  were  assumed  to  be  "well-placed"  with 
respect  to  the  accessing  transactions  and  thus  the  tran¬ 
sactions  required  the  smallest  number  of  granules  that 
were  required  to  "cover"  the  touched  entities. 

The  I/O  overlap  parameter  was  set  to  one  which 
results  in  orly  ore  transaction  processing  an  I/O  opera¬ 
tion  at  ore  time.  Note  that  for  this  run  the  I/O  rate  is 
four  times  the  CPU  so  that  this  simulates  an  "I/O  bound" 
application.  The  CPU  cost  of  a  lock  was  1/5  that  required 
to  process  an  entity.  Lastly,  the  I/O  cost  of  a  lock  was 
equal  to  the  I/O  cost  of  an  entity.  Hence,  this  initial 
run  simulated  a  lock  table  being  kept  or  secondary 
storage . 

Intuitively,  these  input  parameters  could  be  inter¬ 
preted  as  followes: 

DBSIZE  is  5  million  bytes  (ore  entity  is  1024  bytes) 

Average  transaction  accesses  250,000  bytes  of  data. 

IORATE  of  30  msecs  per  entity  (ore  disk  accesses). 

CPU  RATE  of  7.5  msec  per  entity. 

LIORATE  of  30  msecs  per  lock. 

LCPURATE  of  1.5  msecs  per  lock. 

In  this  interpretation  ore  time  unit  corresponds  to  150 


mil  1 i seconds  . 
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For  these  simulation  rurs,  the  value  TMAX  =  19000  was 
chosen  after  running  simulations  for  various  smaller 
values  including  TMAX  =  2500.  In  all  cases,  no  change 
(except  for  scaling)  was  observed  in  the  output  parameters 
between  TMAX  =  2500  and  TMAX  =  10000.  For  some  of  the 
experiments  discussed  later,  other  values  of  TMAX  were 
required  to  guarantee  convergence.  Keeping  the  other 
parameters  fixed,  the  number  of  granules  was  varied 
between  1  and  5000.  The  output  from  the  simulations  is 
presented  in  Tables  2-7  and  2-8. 


Note  that  the  utilization  of  I/O  resources  for  tran¬ 
saction  processing,  USEFULIO,  peaked  at  40  granules. 
Within  }%  of  this  value  was  reached  with  only  10  locks. 
The  useful  1/0  remained  relatively  constant  until  the  lock 
I/O  costs  start  to  be  a  significant  fraction  of  I/O  time. 
For  a  small  number  of  granules,  high  lock  I/O  cost 
resulted  from  lock  conflicts  which  generated  still  more 
lock  I/O.  (In  an  actual  implementation  of  a  locking 
scheme,  a  small  number  of  locks  could  easily  be  maintained 
in  primary  memory.  This  alternative  is  explored  subse¬ 
quently.)  Similai  iy,  the  useful  CPU  time  peaked  at  30 
granules,  ard  again  this  value  was  almost  reached  (within. 
1%)  with  as  few  as  10  granules.  These  results  are  por¬ 
trayed  graphically  in  figure  2-2.  The  lock  CPU  costs  were 
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Table  2-7 

CP'i  ar.d  I/O  Utilization 
Initial  Scenario 


NO  of_G R A  NUL 5‘5 

USEFUL IO 

USFFULCPU 

LOCK  10 

LOCKCPU 

1 

7041.957 

1759.906 

1282.000 

12.820 

2 

8376.933 

2091 .914 

970.000 

9 . 700 

3 

9002.256 

2237.415 

777 . 000 

7.770 

4 

9030.253 

2258.925 

671 . 000 

6.710 

5 

9273.915 

2304 . 927 

604 . 000 

6 . 040 

7 

9433.514 

2309 . 940 

474 . 000 

4.740 

9 

9449 . 087 

2337 . 442 

428 . 000 

4 . 280 

10 

9476 .130 

2324.941 

437 . 000 

4  .  370 

15 

9425.585 

2358.445 

403 • 000 

5.210 

20 

9437.987 

2354 . 943 

396 . 000 

5 . 280 

30 

9534 . 303 

2377 . 449 

371 . 000 

6.720 

40 

9572.718 

2354.949 

360 . 000 

7.900 

50 

9504.073 

2339.950 

360.000 

8.790 

75 

9448.435 

2332.452 

454 . 000 

13.290 

100 

9378.277 

2324.951 

482 . 000 

15.430 

125 

9351  . 744 

2316.457 

547.000 

20 . 890 

150 

9304 .128 

2279.960 

613.000 

23.700 

200 

9159.688 

2259.959 

753-000 

30.000 

250 

91  10.531 

2249.964 

806.000 

36.740 

300 

8768.228 

2177.465 

1015.000 

43.470 

500 

8517.211 

2097 . 466 

1390.000 

69 . 499 

750 

7820.61  1 

1919.974 

1950.000 

94 . 439 

1000 

7359.828 

1814.976 

2462.000 

128.099 

2500 

4764 . 175 

1  1  89. 989 

4824.000 

241 . 199 

5000 

3408.635 

824 . 992 

6120.000 

305.998 

minimized  with  10  granules.  With  fewer  granules,  the 
request  failure  rate  caused  enough  re-requests  for  locks 
that  the  overall  CPU  costs  for  locking  increased.  With 
more  than  10  granules,  the  reductior  in  lock  request 
failures  did  rot  offset  the  costs  of  setting  the  addi¬ 
tional  locks  required  for  each  tr an  sac ti on  . 
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Table  2-8 

Transaction  throughput  men sur ener:  t s 
Initial  Scenario 

AVERAGE 


N0_of  GRANULES 

RESPONSE 

TIME 

COMPLETED 

1 

751  .914 

1  28 

2 

557.232 

168 

3 

534 . 399 

178 

A 

523 . OR? 

182 

5 

490 . 297 

195 

7 

506.667 

1  89 

9 

515.117 

188 

10 

472 . 330 

202 

15 

4  84 .21  4 

1  96 

20 

462 . 678 

208 

30 

472 . 732 

205 

A0 

454  .  189 

212 

50 

441  .  537 

218 

75 

430.543 

223 

100 

4  2  0 . 4  1  6 

231 

125 

463.255 

208 

150 

460.429 

210 

200 

435.748 

222 

250 

504 . 021 

192 

300 

447 . 065 

215 

500 

472.088 

204 

750 

570 . 089 

168 

1000 

546.023 

175 

2500 

815.784 

1  15 

5000 

1 054 . 988 

36 

The  average  resporse  time  and  the  total  number  of 
transactions  completed  at  time  TMAX  reached  extremums  at 
100  granules.  With  this  number  of  granules,  the  smaller 
tran  saction  s  requiring  less  resources  were  able  to  rur.  to 
completion.  Thus,  a  'shortest  job  first’  property  was 
observed.  Moreover,  with  finer  granularity  (>200 
granules)  locking  overhead  actually  increased  the  average 
resporse  time.  In  these  cases  the  higher  I/O  locking 


46 


overhead  (753  to  over  6000  time  units)  delayed  the  normal 
processing  of  transactions. 

In  summary,  urder  the  initial  scenario  parameter  set¬ 
tings,  the  useful  computer  utilization  increased  as  the 
number  of  granules  increased  then  leveled  off  and  fell. 
Moreover,  the  maximum  utilization  occurred  with  a  rela¬ 
tively  small  number  of  granules  and  that  utilization  was 
within  1%  of  that  optimum  for  10  granules.  The  conclusion 
can  be  drawn  that  crude  locking  schemes  with  coarse  granu¬ 
larity  were  nearly  optimal.  Since  a  crude  locking  system 
may  be  easier  to  implement  than  a  sophisticated  finer 
granularity  scheme,  it  may  be  preferred. 

For  this  case,  response  time,  and  throughput  were  all 
better  with  a  small  number  of  granules.  Hence,  a  large 
number  of  granules  (such  as  would  be  required  to  lock  disk 
sectors  or  individual  records)  may  be  inappropr iate . 

—  However,  changes  in  the  parameters  and  simulation 
model  do  alter  these  observations.  In  the  rext  section., 
the  effects  of  alternate  workload  parameters  are  reported. 
In  section  3-3,  the  systems  parameters  are  v  ar  ied .  In 
section  3.4,  the  effects  of  two  extensions  to  the  model 


ar e  reported . 


3.2.  Effects  of  Workload  Parameter s 

Charges  in  the  workload  parameters  would  reflect 
charges  in  the  characteristics  of  the  aoplicatiors  which 
were  running  or  the  system.  It  has  been  noted  already 
that  the  number  of  transactions  had  little  effect  or  the 
observed  output  parameters.  Other  workload  parameters  did 
make  some  difference  or  the  optimum  granularity.  The 
major  difference  was  due  to  the  lock  placement  assump¬ 
tions.  Other  workload  parameters  tested  included  changes 
in  transaction,  sizes,  changes  in  database  sizes  and  the 
addition  of  an  idle  time  period  for  the  transactions. 

3.2.1.  Placement  of  Locks 

In  the  previous  experiments  the  locks  were  assumed  to 
be  well-placed.  The  other  two  placement  assumptions  were 
also  tested.  In  the  worst  case  assumption,  each  transac¬ 
tion  required  the  maximum  number  of  granules  possible.  In 
the  random  placement  assumption,  the  probability  of 
accessing  any  entity  was  identical  and  in de per: dent  of  any 
previous  entities  accessed. 

Which  model  is  chosen  affects  the  previous  observa¬ 
tions.  If  the  "worst  case"  is  chosen,  the  following 
intuitive  analysis  applies.  In  figure  2-3  it  is  assumed 


that  all  transactions  touch  the  seme  number  of  entities, 
NE.  The  machine  utilization  measures  would  decrease  as 
the  number  of  locks  for  the  entire  database  increased  from 
or.e  to  NE.  The  decrease  is  because  each  transaction  would 
require  more  locks  thus  increasing  the  locking  overhead. 
However,  there  would  be  no  additional  parallelism  because 
each  transaction  locked  the  entire  database. 

The  utilization  would  increase,  however,  as  the 
number  of  locks  increased  from  NE  to  the  total  number  of 
entities  in  the  database.  In  this  case,  the  cost  of  the 
locking  overhead  would  remain  constant  while  the  allowed 
concurrency  increased.  The  locking  overhead  would  remain, 
constant  since  each  transaction  could  never  set  more  than 
NE  locks. 

Consequently,  the  optimum  number  of  locks  would  be 
very  dependent  on.  the  transaction  sizes  in  the  worst  case 
placement  lock  assumption.  Moreover,  it  would  always 
occur  at  1  granule  or  the  maximum  number  of  granules 
(corresponding  to  ore  lock  per  entity)  if  all  the  transac¬ 
tions  were  the  same  size.  The  effects  of  having  varying 
transaction  sizes  will  be  discussed  below. 

The  simulation  model  was  run  for  each  of  the  three 
placement  assumptions  under  a  wide  variety  of  parameter 
settings.  Figures  2-'i  and  2-5  diagram  some  of  the 
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results.  In  figure  2-4,  the  transaction  sizes  were  deter¬ 
mined  by  an  exponential  distribution  with  a  mean  value  of 
500  entities  (10%  of  the  database).  In  figure  2-5,  the 
transaction  sizes  were  also  determined  by  an  exponential 
distribution  but  with  a  mean  value  of  5  entities  (0.1%  of 
the  database).  For  these  runs,  the  locks  were  assumed  to 
be  in  main  memory  (no  lock  I/O  required)  and  the  I/O  and 
CPU  time  required  by  the  tr an  sac tion s  were  equal.  These 
conditions  were  chosen  as  the  ores  most  favorable  to  finer 
granularity.  The  other  parameters  were  identical  to  those 
described  in  the  initial  scenario,  with  one  major  excep¬ 
tion.  In  figures  2-4  and  2-5,  the  random  lock  conflict 
assumption  is  assumed  for  all  three  placement  conditions. 
Under  the  random  lock  conflict  assumption,  the  granules 
associated  with  each  transaction  are  considered  to  be  com¬ 
pletely  uncorrelated.  This  modification  is  made  primarily 
for  validity  checking.  With  the  same  lock  conflict  assump¬ 
tions,  the  end  points  (1  and  5000  granules)  should  and  did 
result  in  identical  simulation  runs  under  the  three  lock 
placement  assumptions. 

The  top  curves  in  both  figure  2-4  and  2-5  were  con¬ 
sistent  with  the  results  of  the  initial  scenario.  The 
bottom  two  curves  renresent  the  worst  case  and  random 
access  assumptions. 
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Figure  2-4:  Computer  utilization  as  a  function  of 
no.  of  granules. 

Large  transactions  and  Different  Lock 
Placement  Assumptions 


For  large  transactions  requiring  about  10%  of  the 
database  (see  figure  2-4)  a  smaller  number  of  granules  was 
still  to  be  prefered  to  a  lock  tor  each  entity.  For  small 
transactions  requiring  about  0.1%  of  the  database  (see 
figure  2-5)  one  lock  per  entity  produced  the  greatest 
machine  utilization  under  the  worst  case  and  random  place¬ 
ment  assumptions.  However,  even  with  small  tr  an  sac  ti  or.  s  , 
the  degree  of  improvement  was  small  as  the  granularity 
increased  beyond  a  certain  limit.  For  example,  90%  of  the 
maximum  machine  utilization  was  reached  with  200  locks. 

Next,  the  simulation  was  run  with  mixed  size  transac¬ 
tions  ( AMEAN  =  250,  3MEAN  =  5,  ALPH  =  .1)  using  the  best 
case,  the  worst  case  and  random  access  assumptions. 
Intuitively,  this  simulates  a  few  large  transactions  and 
many  small  ones.  As  previously  stated,  under  the  well- 
placed  assumption  a  small  number  of  granules  is  best.  A 
relatively  flat  curve  relating  machine  utilization  and  the 
number  of  locks  is  observed  for  the  worst  case  and  random 
access  assumptions.  Thus,  in  these  two  cases,  the  granu¬ 
larity  of  locks,  whether  coarse  or  fine,  did  rot  greatly 
effect  the  useful  machine  utilization.  In  fact,  9B%  of 
the  maximum  utilization  was  achieved  with  both  10  and  2500 
granules.  The  basic  problem  with  fine  granularity  was 
that  the  expense  of  rurring  just  a  few  large  transactions 
seemed  to  outweigh  the  gain  due  to  the  increased  cor- 
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currency  experienced  by  the  small  transactions. 

3.2.2.  Size 

Under  a  uniform  distribution  of  transaction  sizes, 
the  number  of  entities  required  by  a  transaction  was 
determined  by  the  RAD  parameter.  The  simulation  was  run 
under  the  well-placed  lock  assumptions  with  RAD  values  of 
1,  25,  50,  100,  250  and  500  or  a  data  base  containing  5000 
granules.  The  first  case  results  in  an  initial  average 
transaction  size  of  1/1000  th  ( 1 *NTRAN/2 )of  the  database. 
The  last  case  on  the  other  hand,  results  in  an  average 
transaction  size  requiring  one  half  ( 500*NTR AN /2 )  of  the 
entities  in  the  database. 

As  the  needs  of  the  transactions  increased,  maximum 
machine  utilization  and  throughput  were  obtained  with 
fewer  and  fewer  granules.  Minimum  response  time  behaved 
similarly.  The  optimum  1*  and  5%  intervals  of  useful  I/O 
are  presented  in  figure  2-6.  Note  that  even  for  very 
small  transactions,  95"  of  the  optimum  was  reached  with  as 
few  as  10  granules. 

The  two  other  d  i  s  t  r  i  hut  i  or1  s  of  the  transaction  sizes 
were  also  tested  in  order  to  model  different  transaction 
environments.  With  an  exponential  distribution,  with  the 
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same  mean  value  as  the  uniform  distribution 
( AMEAN=RAD*NTRAN/2  ),  the  results  were  very  similar.  For 
a  small  AMEAN,  say  5  entities,  500  granules  were  optimal. 
Again,  however,  10  granules  produced  useful  machine  utili¬ 
zation  within  5%  of  the  utilization  realized  with  the  500 
granules.  With  an  exponential  distribution  and  an  AMEAN 
value  of  250  entities,  on  the  other  hand,  40  granules  was 
again  optimal.  In  that  case,  the  larger  transactions 
realized  too  much  locking  overhead  with  the  less  coarse 
granularity . 

However,  with  a  hyper-exponer. tial  distribution,  the 
"large"  tr ansacticr s  (those  determined  by  the  BMEAN  param¬ 
eter)  dominated  the  processing.  Thus  coarse  granularity 
was  again  favored.  For  example,  with  AMEAM,  BMEAN,  and 
ALPH  values  of  5,  250  and  0.1  respectively,  an  NGRAN  of  50 
still  produced  the  maximum  useful  computer  utilization. 
In  this  case,  the  average  transactior  size  was  about  30 
entities.  But  10  percent  of  the  transactions  accessed  on 
the  average  250  entities  and  these  transactions  dictated 
coarse  granularity. 

The  simulation  was  also  run  under  the  random  lock 
placement  assumptions  varying  the  granularity  ard  transac¬ 
tion  sizes.  For  these  experiments,  the  IORATE  and  CPURATE 
were  again  equal  and  the  LIORATE  was  set  to  zero.  The 
other  parameters  were  identical  to  those  described  in  the 
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initial  scenario.  With  an  average  transaction  size  of 
less  than  25  entities,  the  finest  granularity  was  agair 
optimal.  When  the  average  transaction  size  was  between  25 
and  50  entities,  the  useful  computer  utilizations  at  1  and 
5000  granules  were  appr ox imatel y  equal.  With  an  average 
transaction,  size  greater  than  50  entities  (1%  of  the  data¬ 
base),  ore  granule  was  ontimal. 

3.2.3.  Database  Size 

Simulation  experiments  were  also  run  with  various 
granularities  or  a  database  of  50000  entities.  The  aver¬ 
age  transaction  size  was  fixed  at  250  entities  and  the 
simulation  was  rur.  for  15000  time  units.  The  effects  of 
increasing  the  database  size  was  similar  to  the  effects  of 
decreasing  the  transaction  size.  With  well-placed  locks, 
the  optimal  granularity  occurred  at  500  granules.  In  this 
case,  five  percent  of  the  maximum  utilization  was  realized 
with  20  to  2500  granules.  With  random  lock  placement,  the 
finest  granularity  was  again  optimal. 

3 . 2  J)  .  Idle  Time 

For  some  appl icatior s ,  locks  car  be  held  while  a  user 
or  aDolicatior  program  pauses  for  some  duration  (often 
thought  of  as  "head  scratching").  The  simulation  was 
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modified  to  reflect  this  effect  by  holding  all  locks  for 
an  idle  period  of  100  time  units  (say,  for  examole,  about 
25  seconds  in  the  inter pretaticr  mentioned  at  the  begin¬ 
ning  of  this  section).  The  simulation  was  then  run  with 
the  parameter  settings  of  the  initial  scenarios  shown  in 
Tables  2-5  and  2-6. 

The  results  were  remarkably  similar  to  those  ir.  Table 

2- 2.  The  useful  I/O  curve  had  slightly  more  variation 
than  the  curve  in  figure  2-2  with  a  peak  occuring  at  50 
granules.  Ten  granules  still  produced  useful  I/O  and  CPU 
times  within  55?  of  the  optimum.  Hence  a  small  number  of 
granules  was  still  best  even  with  substantial  pauses  in 
the  transaction  processing. 

3- 2.5.  Workload  Parameter  Summary 

The  lock  placement  assumptions  clearly  had  the  most 
dramatic  impact  or:  the  machine  utilization  as  a  function 
of  locking  granularity.  The  second  most  important  parame¬ 
ter  was  the  size  of  the  transactions  accessing  the  data¬ 
base  . 


Fine  granularity  may  be  best  if  the  following  two 
conditions  were  meet:  1)  almost  all  of  the  transactions 
are  small  and  2)  access  patterns  are  random  with  no 
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sequentiality.  Under  these  conditions,  the  g renter  the 
number  of  locks.  the  greater  the  machine  utilization.. 
However,  the  rate  of  increase  dropped  dramatically  after  a 
certain  level  of  granularity  was  obtained  (about  200 
granules  in  our  simulation).  Hence  "medium"  granularity 
did  almost  as  well  as  fine  granularity;  coarse  granularity 
was  unacceptable  in  these  cases. 

If  too  many  of  the  transactions  access  a  large  por¬ 
tion  of  the  database,  fine  granularity  produces  too  much 
locking  overhead  and  coarse  granularity  was  again  to  be 
preferred . 

Regardless  of  the  transaction  sizes,  if  the  data 
access  patterns  were  primarily  sequential,  coarse  granu¬ 
larity  was  still  the  most  effective. 

3-3.  Effects  of  the  System  Parameters 

The  locking  granularity,  determined  by  NGRAN,  has 
been  the  major  system  parameter  studied  so  far.  This 
parameter  is  clearly  the  ore  over  which  the  system  imple¬ 
mentors  have  the  most  control.  The  effects  of  the  other 
system  parameters  or  the  system  throughput  and  utilizatior 
are  presented  below.  In  particular,  the  IQRATE  and  I00VLP 
parameters  were  varied  in  order  to  "balance"  the  1/0  and 
CPU  requirements  of  the  transactions.  Also,  the  LTORATE 
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and  LCPURATE  oarameters  were  varied  to  control  the  locking 
overhead.  In  additior,  for  each  parameter,  its  ir.terac- 

A 

tior:  with  the  locking  granularity  is  also  discussed. 

3.3*1.  I/O  \^er sus  C PI  1  Ba  1  an ce 

The  effects  of  the  ratio  of  the  required  I/O  time  to 
the  required  CPU  time  per  entity  was  investigated.  The 
CPU  rate  (CPIJRATE)  per  entity  for  a  transaction  was  held 
fixed  at  .05  units/entity.  The  simulation  was  run  with 
I/O  rates  (IORATE)  per  entity  set  at  .01,  .05,  .1,  .2,  and 

.3.  For  each  setting  of  the  I/O  rate,  the  number  of 
granules  (NGRAN)  was  varied  from  1  to  5000.  The  lock  I/O 
rate  per  granule  was  set  equal  to  the  I/O  rate  per  entity 
in  order  to  reflect  the  locks  being  on  the  same  speed  dev¬ 
ice  as  the  data.  F.ach  simulation  ran  for  5000  time  units. 
The  cither  input  parameters  had  the  values  indicated  in 
Tables  2-5  and  2-6. 

Under  the  well-placed  lock  assumption,  the  useful  I/O 
curves  for  each  setting  of  IORATE  were  bell  shaped  and 
heavily  skewed  towards  a  small  number  of  granules.  As 
such  they  were  similar  to  the  curves  in  figure  2-2  ar d  are 
not  repeated  hf’re.  The  peak  of  these  curves  occ  urred  with 
somewhat  finer  granularity  as  the  IORATE  came  closer  to 
the  CPURATE.  With  a  system  balanced  betweer  I/O  arid  CPU 


61 


requirements  the  maximum  utilization  of  both  CPU  and  I/O 
resources  was  possible.  However,  even  with  balanced  tran¬ 
sactions,  100  granules  were  sufficient  to  achieve  the  max¬ 
imum  machine  utilization.  With  CPU  bound  transactions 
(CPURATE  >I0RATF.)  within  5%  of  the  peaks  was  reached  with 
as  few  as  10  granules.  Varying  the  IORATF  had  little 
effect  on  the  throughput  measuremen ts  (average  response 
time,  and  number  of  transactions  completed)  as  a  function 
of  the  number  of  granules  allowed.  The  useful  CPU  time, 
as  a  function  of  granule  size,  showed  a  similar  distribu¬ 
tion  as  the  useful  I/O.  The  costs  associated  with  locking 
were  again  minimized  with  100  granules. 

Under  the  random  and  worst  case  placement  assumptions 
and  small  transactions,  the  finest  granularity  was  optimal 
regardless  of  the  I/O  to  CPU  balance. 

3 -3.2.  Multiple  I/O  Paths 

One  method  of  "balancing"  a  system  that  is  I/O  bound 
is  to  increase  the  number  of  I/O  channels  to  main  memory. 
In  the  previous  runs,  the  I00VLP  value  was  ore.  These 
experiments  thus  simulated  a  system  with  ore  I/O  path 
between  main  memory  and  secondary  storage.  In  the  next 
series  of  runs,  this  parameter  was  set  to  three  and  six  to 
simulate,  for  example,  a  database  environment  with  three 
and  six  disk  drives  respectively.  Other  input  parameters 
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were  the  same  as  in  Tables  2-5  and  2-6. 


Except  for  greatly  increased  magnitude,  the  output 
parameters  had  a  similar  d istr ibution  as  those  in  Table 
2-7.  The  useful  I/O  time  (IJSEFULIO)  versus  the  granular¬ 
ity,  for  simulation.  runs  under  the  well-placed  lock 
assumptions,  are  shown  in  figure  2-7.  Note,  with  10  to 
100  granules,  the  useful  T/0  increased  by  a  factor  of 
about  2.5  for  three  I/O  paths  as  compared  to  the  useful 
I/O  with  one  I/O  path.  (The  best  results  possible  would 
be  increased  useful  I/O  by  a  factor  of  3.)  Moreover,  as 
the  number  of  granules  increased  three  drives  became  less 
and  less  effective.  For  2500  granules,  for  example,  only 
a  1.5  factor  increase  in  useful  I/O  was  realized.  The 
results  for  six  I/O  paths  were  similar.  Ten  to  one  hundred 
granules  tripled  the  increase  in  useful  1/0.  With  25 00 
granules,  the  increase  in  useful  I/O  was  slightly  less 
than,  doubled  . 

In  the  random  and  worst  case  lock  placement  experi¬ 
ments,  the  finest  granularity  was  again,  favored  as  addi¬ 
tional  parallelism  was  made  possible. 

3.3.3.  Lock  1/0  Costs 

In  the  previous  experiments,  the  lock  1/0  rate 
(LI0RATE)  was  equal  to  the  transaction  I/O  rate  (IORATF. ). 


Useful  I/O  lime 


No.  of  granules  (  log  scale  ) 

EFFECTS  OF  MUl.TIl’LK  I/O  PATHS 
We)  1 -pl.ii  i'il  lock  assumption. 
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In  the  next  series  of  simulation  runs,  only  the  lock  I/O 
rate  and  the  granularity  were  varied.  The  simulation  was 
run  with  other  parameters  as  in  Tables  2-5  and  2-6.  The 
useful  I/O  times  (USEFULIO)  for  the  well-placed  lock 
assumptions  are  shown  in  figure  2-8. 

As  the  lock  I/O  rate  decreased,  a  larger  number  of 
granules  could  be  afforded  before  the  advantages  of  more 
parallelism  were  outweighed  by  the  locking  overhead.  Of 
particular  interest  is  the  situation  where  the  LIORATE  was 
zero.  This  case  is  analogous  to  keeping  all  locks  in 
main  memory.  Even  with  no  lock  I/O  costs,  there  was  a 
very  flat  extremum  for  USEFULIO  between  10  and  200 
granules.  Having  a  granule  correspond  to  fewer  than  25 
database  entities  (number  of  granules  >  200)  resulted  in 
noticeably  poorer  performance.  If  the  interpretation  of 
an  entity  is  a  612  byte  page  (or  a  4096  byte  sector)  a 
database  management  system  should  thus  not  'protect'  less 
than  13,000  (or  100,000)  bytes  of  data  with  one  lock. 

3 . 3 • 4  .  Lock  CPU  Costs 

The  CPU  costs  for  setting  one  lock  were  dependent  or 
the  lock  management  algorithms.  To  investigate  the 
effects  of  varyirg  the  CPU  rate  for  locking  or  the  desired 
granularity,  the  simulation  was  run  with  CPU  lock 


(LCPURATE)  corts  per  lock  of  .005,  .01,  .025,  .05  .  .075, 


and  .1.  For  this  series  of  experiments,  the  LI0RATE  was 
set  to  zero  to  simulate  the  effects  of  maintaining  all 
locks  in  main  memory.  Other  parameters  were  as  in  Tables 
2-5  and  2-6. 

Under  the  well-placed  lock  assumption  and  a  small 
number  of  granules,  the  CPU  lock  costs  (L0CKCPU)  were 
approximately  linearly  proportional  to  the  CPU  rate  per 
lock  (LCPURATE).  In  these  cases,  there  were  enough  unused 
CPU  resources  available  for  locking.  For  a  large  number 
of  granules,  however,  the  CPU  lock  costs  increased 
slightly  less  than  linearly  with  LCPURATE.  In  these 
cases,  the  locking  CPU  utilization  interfered  with  normal 
transaction,  processing.  For  all  CPU  lock  costs  tested, 
however,  the  minimum  locking  costs  occurred  at  10 
gr an  ules . 

Under  the  well -placed  lock  assumption  the  maximum 
amount  of  useful  C P' l  and  I/O  occurred  with  10  to  100 
granules  and  was  about  the  same  regardless  of  the  lock  CPU 
rate.  With  lock  CPU  rates  of  less  than  1  millisecond 
(LCPURATE  =  .005),  the  peak  occurred  at  100  grarules; 
within  1%  of  that  peak  occurred  with  10  to  1000  grarules. 
With  lock  CPU  rates  between  1  and  5  millisecords  (LCpURATE 
=  .005  to  .03)  the  peak  was  at  50;  but  the  useful  1/0  and 
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CP'J  dropped  off  sharply  with  more  than  200  granules.  With 
higher  lock  CPI)  rates,  10  granules  were  optimal  and  at 
most  100  granules  for  the  locking  granularity  were  afford¬ 
able. 

Simulation  experiments  were  also  run  varying  the  lock 
CPU  costs  under  the  random  lock  placement  assumption.  In 
these  experiments  all  transactions  were  small  (AMEAN  =  5, 
ALPH  =  0)  and  the  LIORATE  was  again  set  to  zero.  The  CPU 
and  I/O  rates  for  transaction  processing  were  both  about 
30  mil  1 i second s  per  entity  (IORATE  =  CPURATE  =  .2).  In 
these  experiments,  an  increase  in  lock  CPU  rates  greatly 
affected  the  computer  utilization  at  the  finest  granulari¬ 
ties.  With  a  5  millisecond  lock  cost  (LCPURATE  =  .03), 
the  useful  computer  utilization  was  5%  of  the  utilization 
observed  with  a  2.5  millisecond  lock  overhead  cost 
(LCPURATE  =  .015).  However,  the  finest  granularity  was 
still  optimal  until  a  15  millisecond  per  lock  overhead 
cost  (LCPURATE  =  .1)  was  incurred. 

3-3.5.  System  Parameter  Nummary 

Some  of  the  system  parameters  did  suggest  somewhat 
finer  granularity  under  the  well-placed  lock  assumDtiors. 
In  particular,  two  factors  had  some  effect  on  the  optimum 
granularity.  When  the  resources  expended  for  locking  were 
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reduced,  finer  granularity  was  affordable.  With  lock  I/O 
costs  of  zero  and  the  lowest  setting  of  lock  CPU  costs, 
100  locks  was  optimal.  Even  in  these  cases,  though,  too 
fine  a  lock  granularity  was  not  acceptable. 

The  second  factor  which  had  an.  effect  on  the  optimum 
granularity  was  the  balance  between  the  CPU  and  I/O 
resource  needs  of  the  transactions.  Under  a  balanced  sys¬ 
tem  load  and  the  well-placed  lock  assumption  50  to  100 
locks  were  again  optimal. 

Under  the  random  and  worst  case  lock  placement 
assumptions,  in  most  cases,  the  lock  cost  parameters 
(LCPURATE,  LI0R4TE)  did  rot  change  the  optimal  granular¬ 
ity.  The  other  system  parameters  had  no  affect  or.  the 
optimum  granularity  under  these  placement  assumptions. 

3 . ^ .  System  Extensions 

In  the  previous  experiments  all  granules  were  assumed 
to  be  the  same  size  and  all  of  the  locks  were  acquired  at 
the  beginning  of  a  transaction.  In  this  section  two 
mod  i  f  icat  i  or:  s  to  the  model  are  introduced  to  study  alter¬ 
nate  assumptions.  In  the  first  extension  a  lock  hierarchy 
is  simulated.  In  a  lock  hierarchy,  transactions  of  d  l  f- 
ferent  sizes  lock  different  sized  granules.  In.  the  secord 
extension,  a  "claim  as  needed"  locking  strategy  is  simu- 
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lated.  I  r.  that  strategy,  tr  an  sac  ti  or:  s  acquire  locks  as 
they  need  the  corresponding  entities. 

3.^.1-  Lock  Hierarchy 

In  many  of  the  previous  experiments  it  is  noted  that 
the  expense  of  locking  a  large  number  of  granules  by  a 
large  transaction  offsets  any  increase  in  parallelism 
realized  by  fine  granularity.  One  way  a  large  transaction 
can  avoid  the  expense  of  locking  many  small  granules  might 
be  to  have  the  large  transactions  lock  large  granules 
while  the  small  transactions  continue  to  use  the  small 
locks  [GRAY76], 

3  . ^ .  1  .  1_ .  Thj?  Model.  Ex_tersix)n 

In  the  simulation  extension  a  two  level  hierarchy  was 
implemented.  A  transaction,  depending  or  its  size,  either 
requested  a  set  of  small  locks  or  ore  global  lock  which 
covered  the  entire  database. 

With  this  extension,  we  explored  the  in  ter ac ti or s 
between  any  two  levels  of  a  more  general  hierarchy.  A 
more  general  hierarchy  could  be  ary  tree-like  graph  struc¬ 
ture.  A  transaction,  could  lock  the  root  of  a  subtree  and 
thus  control  access  to  the  parts  of  the  database  covered 
by  any  locks  in  that  subtree.  Alternately ,  the 
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t  r  at:  sac  t  i  or  s  could  mark  the  root  of  the  subtree  to  indi¬ 
cate  that  locking  is  taking  place  at  a  lower  level.  The 
transaction  would  then  treat  each  offspring  of  the  root  as 
its  own  subtree . 

In  the  extended  model  ,  the  choice  between,  the  global 
locks  and  the  small  locks  simulates  the  choice  between  the 
root  of  ore  subtree  and  its  direct  descerdents.  The  per¬ 
formance  tradeoffs  between  increased  parallelism  and 
increased  locking  overhead  of  a  more  general  hierarchy 
occur  similarly  at  each  node.  Thus,  the  results  of  this 
extension  can  be  applied  to  the  more  general  hierarchy  and 
a  more  complex  tree  structure  need  not  be  simulated. 

The  simulation  was  modified  by  adding  'pending'  and 
'blocked'  queues  for  the  global  lock.  If  a  transaction 
was  "small",  it  set  the  global  lock  in  shared  mode  and  was 
placed  or:  the  original  pending  queue.  From  that  queue  the 
"small"  transactions  competed  for  the  small  locks  as  in 
the  original  model.  If  the  transaction  was  "large",  the 
global  lock  was  set  for  exclusive  access  and  the  transac¬ 
tion  waits  for  all  active  transactions  to  finish.  With 
the  global  lock  set  for  exclusive  use,  new  transactions, 
regardless  of  size  would  also  wait  in  the  blocked  queun  . 
Once  the  large  transaction  was  allowed  to  proceed,  it  went 
directly  to  the  I/O  queue  bypassing  the  s  nail  lock  cor - 
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The  simulation  was  used  to  study  the  effects  of 
tain  parameters  of  such  a  hierarchy  or  the  desired  grar.u- 
larity.  One  of  the  main  areas  of  lr.terest  was  the  cri¬ 
teria  for  d ec  id  ir:  g  whether  the  small  locks  or  the  global 
lock  should  be  used.  An  input  parameter  was  added  to  the 
simulatior:  which  specified  the  threshold  percentage,  TP, 

of  the  database  which  must  be  touched  by  a  transaction 
before  it  was  declared  "large".  If  a  transaction  used 
less  than  TP  percent  of  the  database,  the  small  locks 
would  be  used.  Otherwise,  orly  the  global  lock  would  be 
set . 

3.4. 1.2.  The  Simulation  Results 

The  simulation  was  run  with  threshold  percentages  of 
0.1%,  0.2%,  0.5%,  1%,  2%,  5%,  25%,  50%  and  100%  for  each 

of  a  large  number  of  other  parameter  settings  in  order  to 
find  the  value  of  TP  which  maximized  useful  machine  utili¬ 
zation.  The  optimum  threshold  observed  was  dependent  on 
the  number  of  small  locks,  the  assumptions  concerning  the 
placement  of  those  locks,  the  number  of  entities  touched 
by  the  tr an  sac ti or s  ,  and  the  size  of  the  database. 

figure  2-9  shows  the  effects  of  the  threshold  percer- 
or  machine  utilizatior  in  two  instances  with  dif- 
-tj-'-crs  of  small  locks.  For  both  of  those  cases 
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Figure  2-9:  Computer  Utilization  versus 
Threshold  Percentage  in  a 
Lock  Hierarchy. 
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were  assumed.  With  ter  smal  l  looks  ,  the  m.ix  huti  ma<.  hi r  e 
utilizatior  was  reached  with  thresholds  of  BO  ard  100  per¬ 
cent.  A  threshold  of  100®  resulted  ir:  all  trar:  r.ncti  or  s 
usinr,  the  small  locks,  i.e.  as  if  no  hierarchy  were 
present.  However,  with  1000  small  locks,  for  example,  a 
threshold  of  5  percent  was  optimal.  Charging  the  assump¬ 
tion  about  the  placement  of  the  locks  also  made  a  dramatic 
difference. 

Figures  2-10  and  2-11  further  explore  the  effects  of 
the  number  of  small  locks  or:  the  threshold  oercertages. 
The  results  ir  Figure  2-10  reflect  the  "well-placed" 
assumption.  Random  access  to  the  database  was  assumed  for 
the  simulation  results  shown  in  figure  2-11. 

Each  of  the  graphs  is  divided  into  three  areas  based 
on  machine  utilizatior  .  The  "optimum"  line  represents  the 
threshold  value,  TP,  at  which  the  maximum  I/O  and  CPU 
utilization  was  observed  for  a  giver  number  of  small 
locks.  With  threshold  values  in  area  5,  the  hierarchical 
locking  produced  results  within  ?%  of  that  maximum  utili¬ 
zatior-.  In  area  A,  the  utilizatior  was  less  than  in  area 
B.  Ip-  this  case,  too  few  transactions  used  the  global 
lock,  i.e.  the  threshold,  TP,  was  too  high.  Ir.  area  C, 
the  machine  utilizatior  was  also  less  than  in  area  B.  In 
this  case,  however,  too  many  transactions  used  the  global 
lock,  i.e.  the  threshold,  TP,  was  too  low. 


For  example,  consider  figure  2-10  with  1000  small 
locks.  The  machine  utilization  increased  as  the  threshold 
percentage  was  increased  from  0 . 1  %  to  5%,  but  decreased  as 
the  threshold  increased  from  5%  to  100%.  However,  simula¬ 
tion  runs  with  threshold  percentages  between  1%  and  25% 
produced  within  2%  of  the  machine  utilization  observed 
with  the  optimum  threshold. 

In  figure  2-10,  " we  1 1-pl ac ed "  granules  were  assumed. 
With  more  than  1000  small  locks  the  optimum  value  of  TP 
was  between  1%  and  5%.  With  the  number  of  locks  between 
10  and  100,  TP  values  of  50%  to  100%  were  optimal.  In 
this  granularity  interval,  the  2%  area  included  the  case 
where  all  transactions  used  only  the  small  locks.  The 
overall  maximum  machine  utilization  occurred  in  figure  2- 
10  with  10  locks  and  TP  values  greater  than  50%.  In  these 
cases,  almost  all  of  the  transactions  used  the  small 
locks.  Hence,  the  value  of  a  lock  hierarchy  under  the 
well-placed  locks  assumption  was  very  small. 

However,  in  figure  2-11,  random  lock  placement  was 
assumed.  With  coarse  granularity,  the  optimum  threshold 
occured  at  0.5%.  With  a  higher  threshold,  mere  of  the 
smaller  transactions  would  use  the  small  locks,  and  conse¬ 
quently  would  lock  a  large  portior  of  the  database.  As  a 
result,  these  transactiors  would  exDend  more  resources  for 
lockirg  than  if  the  global  lock  were  used  without  sigrifi- 
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cantly  increasing  the  concurrency  allowed. 

In  figure  2-11,  the  differences  in  computer  utiliza¬ 
tion  between  areas  A,  B,  and  C  was  small  for  coarse  granu¬ 
larity.  For  10  granules,  for  example,  no  matter  what 
value  of  TP  was  used,  the  computer  utilization  was  within 
3%  of  the  maximum  observed  for  that  granularity.  Simi¬ 
larly,  for  100  granules,  the  computer  utilization  was 
within  15%  of  the  maximum  observed  for  any  value  of  TP. 
Thus  even  with  random  lock  placement,  a  hierarchy  with  a 
small  number  of  small  locks,  at  best,  provided  slight 
improvement  over  a  single  level  locking  system. 

Under  the  random  access  assumptions,  the  overall  max¬ 
imum  machine  utilization  occurred  with  5000  granules  arid  a 
TP  of  1%.  The  cross-hatched  area  in  figure  2-11 
represents  those  combinations  of  TP  and  number  of  small 
locks  which  resulted  in  machine  utilization  within  2%  of 
the  overall  maximum.  Hence,  fine  granularity  was  pre¬ 
ferred.  The  lock  hierarchy  effectively  prevented  exces¬ 
sive  locking  overhead  for  large  trap sacti or s  .  The  coarse 
granularity,  or  the  other  hand,  resulted  in  Doorcr  useful 
machine  utilization  regardless  of  the  TP  setting.  With  11 
granules,  for  example,  the  USFFULIO  was  orly  3/1  of  the 
maximum  USFFULT0  observed  with  5000  granules  are  a  T(J  of 
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For  fine  granularity,  the  B  areas  in  figures  2-10  and 
2-11  had  considerable  overlap.  For  example,  in  figure  2- 
10,  with  2500  small  locks,  the  2%  of  optimum  interval 
occured  with  a  TP  between  0.5%  and  10%.  In  figure  2-11, 
with  the  same  number  of  small  locks,  the  interval  occurred 
with  TP  values  between  0.5%  and  5%.  Thus,  at  this  granu¬ 
larity,  a  TP  between  0.5%  and  5%  could  safely  be  chosen, 
regardless  of  the  randomness  of  the  data  access  patterns. 

In  other  simulation  runs,  as  the  average  transaction 
size  decreased,  the  range  of  acceptable  TP  values  (area  0) 
also  decreased.  With  fine  granularity,  regardless  of  the 
transaction  sizes,  a  threshold  between  1%  and  2%  always 
produced  machine  utilization  within  2%  of  the  maximum. 

With  coarse  granularity,  however,  changes  in  the  size 
of  the  transactions,  created  non-over  lapped  intervals  of 
acceptable  TP  values.  In  other  words,  no  one  value  of  TP 
could  be  chosen  that  would  be  correct  for  vastly  different 
sized  transactions.  Thus  much  greater  care  must  be 
applied  to  a  hierarchy  with  coarse  granularity.  Further¬ 
more,  a  stable  transactior  size  envirormert  must  be 
assumed . 

The  size  of  the  database  was  also  varied.  For  exam¬ 
ple,  the  simulatior  was  run  with  a  database  cersistirg  of 
only  16  entities.  In  this  scenario,  the  Dossibie  irterac- 
tior:  of  a  page/rocord  hierarchy  was  examined.  Ar  entity 
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corresponded  to  one  of  16  records  in  a  page.  The  simula¬ 
tion  was  then  used  to  model  the  effects  of  locking  the 
whole  par,e  by  the  global  lock,  or  locking  individual 
records  by  the  small  locks.  Some  increase  in  machine 
utilization,  was  observed  with  a  threshold  of  50%;  but  the 
increase  over  using  no  hierarchy  at  all  was  less  than  4%. 
Again  it  appeared  that  a  lock  hierarchy  covering  orly  a 
small  number  of  smaller  locks  was  not  worth  implementing. 

The  simulation  was  also  run  with  databases  of  up  to 
100,000  entities.  The  results  were  similar  to  the  results 
produced  with  a  database  of  5,000  entities.  For  example, 
experiments  were  run  where  the  average  transaction  size  of 
most  of  the  transactions  was  just  0.05%  of  a  100,000 
entity  database  and  the  average  size  of  a  few  large  tran¬ 
sactions  is  1%  of  the  database.  In  these  cases,  with  the 
finest  granularity  (100,000  small  locks),  a  threshold  of 
1%  was  still  optimal  . 

Other  simulation  experiments  used  the  worst  case  data 
access  assumption  and  produced  results  very  similar  to 
those  in  figure  2-11. 

3.4.2.  Claim  As  Ne_eded  Locking 

There  is  another  difference  between  the  original 
model  and  some  database  concurrency  cor trol  implements- 


80 


tiors.  In  the  original  model,  a  "preclaim"  strategy  was 
assumed  where  all  of  the  locks  were  acquired  before  any 
transaction  processing  took  place.  In  some  database  sys¬ 
tems,  a  lock  is  not  acquired  until  the  related  entities 
were  actually  needed  by  a  transaction.  These  "claim  as 
needed"  schemes  are  used  either  to  reduce  the  total  time 
locks  are  held  and/or  because  the  locks  to  be  acquired 
depend  on  data  values  of  entities  already  accessed.  In 
these  cases,  some  locks  may  have  to  be  held  while  other 
locks  were  requested,  and  deadlock  can  occur  [C0FF71].  In 
this  section  the  effects  of  a  claim  as  needed  scheme  are 
examined . 

3. 4. 2. 2-  Ttie  Model  Extension 

The  simulation  was  modified  by  cycling  each  transac¬ 
tion  through  the  I/O  and  CPU  queues  (see  figure  2-1)  or.ce 
for  each  lock  required.  The  total  I/O  and  CPU  times 
required  for  a  transaction  were  the  same  as  in  the  origi¬ 
nal  model  and  were  equally  distributed  among  each  of  a 
transaction's  cycles. 

Between,  each  cycle,  a  transactior  requested  ore  lock. 
If  the  lock  was  granted,  the  transaction  went  or  the 
active  queues.  When  a  transactior  completed  its  last 
cycle  or  the  active  queues,  all  its  locks  were  released  as 
in  the  original  model. 


If  the  lock  was  denied,  the  requesting  transactior 
was  placed  on.  the  blocked  queue.  The  lock  could  be  denied 
due  to  locks  held  by  either'  another  active  transaction,  or 
by  a  blocked  transaction.  In  the  latter  case,  the  block¬ 
ing  transaction  was  on  the  blocked  queue,  and  a  deadlock 
condition  could  exist.  If  deadlock  occurred,  a  victim  was 
picked  for  backout.  The  locks  held  by  the  victim  were 
released,  any  blocked  tran sactions  were  freed,  and  any 
time  spent  on  the  active  queues  by  the  victim  was  added  to 
a  "lost  time"  total. 

3. 4. 2. 2.  The  Simulation  Results 

The  modified  simulation  was  run  varying  the  sizes  of 
the  transactions,  changing  the  lock  placement  a ssumpt ion s , 
and  with  and  without  a  lock  hierarchy.  Again  it  was 
assumed  that  there  was  no  I/O  cost  associated  with  locking 
and  that  the  transactions  required  equal  amounts  of  CPU 
and  I/O  resources. 

The  results  of  these  simulation  runs  were  very  simi¬ 
lar  to  the  results  from  the  preclaim  strategy.  In  all 
cases,  a  claim  as  needed  strategy  did  not  change  the 
granularity  required  for  maximum  machine  utilization. 

For  example,  figure  2-12,  shows  the  results  of  run¬ 
ning  the  simulation  with  no  hierarchy,  well  placed 


:hine  utilization 


g  r  ar  u 1  '•  s  nr  d  '  •  . * r  r.noti  .nr  si;'o  r.  <  >;•  ?  «r";ir  o i  by  a  r.vD**”- 
gx  por  or  t  i  •*,  1  d  i  rt  hut  j  -»  .  The  lest,  time  area  i  r  «.  1  ud  ed  the 
mac  hi  r  utilizer  i :  bv  t  r  .j:  bier  s  that.  had  be.  tie  res¬ 

tarted  due  bo  d  e  *i  1 1  c-i-  k  .  The  useful  c  o  m  r  J  t  i  r  g  i  r  c  1  u  d  e d 
or  1 y  the  CPU  resources  used  by  successfully  completed 
trar  sactior.s . 


It:  the  simulatior  exoor  imer  t  s ,  the  locking  cost 
observed  i  r;  the  nr  eel  aim  model  was  greater  thar.  the  lock¬ 
ing  cost  observed  ir  the  claim  as  r eeded  locking  model  . 
Ir.  the  or  eel  aim  model,  ir  the  case  of  a  lo-ck  request 
failure,  all  of  th°  locks  hoi  to  be  requested  acair  .  I r 
the  claim  as  r  eede^  model,  ir  th»  cose  of  a  lock  request 


failure  or.ly  the  der  ied  lock  had  to  be  rerequested. 


how¬ 


ever  ,  ary  decrease  ir'  lock  costs  ir  the  claim  as  reeded 
model  was  more  thar  offset  by  the  lost  time  due  to  res¬ 
tar  tir.fr  tr  ar.  sac  t  i  or.  s  .  Thus,  the  useful  mac  hi  r.  e  utiliza- 
tior  was  greater  ur.der  the  preclaim  model  thar  under  the 
claim  as  reeded  strategy.  Mary  other  cases  with  different 
tr  ar  sac  t  i  or.  sizes  ard  lock  placemert  assumption  s  were  also 
tested  ard  produced  similar  results. 

For  ex  amol  e  ,  figure  ,—11  cnr'i’"'1'  b h ^  u s e  f 1  r  1  m  a  *.  r  i  *  e 


util  i 7  a  tier  b  o  b  w  °  e  r  b  h o  b  wo  models  u  -  ~ . ,  p  \  r,  r  s  s  u  ~  -  b  i  o-  r 
that  all  t r  a r  s a ^  t  r  '  r  r.  «■«'•#  small  ar  d  that  e,n»  h  t  r  a r  s  a  >.  tier 
had  random  data  access  mtterrs.  Ir  both  of  these  ruts, 
the  average  trar  sac* ior  rizQ  was  C.1%  of  the  database. 
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"Proclaim"  versus  "Clair:  '  Needed" 
with  Random  Placement  of  Lock.-. 


Figure  2-13 
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Note  t.  hat,  w  i  t  h  t  '■V'1  p  o  s  3  i  b  i  1 1 1  v  :  d  e  a  : !  •:  ,  ?f.  ;u  ■:.*  '• 

ut  i  1 i zatior  curvft  iii  r  -,?  f1  at  v  •:  out  as  th"  ’,rn:  ul  :r:tv 
i  rcroar.?  i  .  Thus  ,  the  forest.  r*rar  ul  ar  i  t  v  i  r.  :  .  :rhtly  more 
ber  ef  it  ial  with  the  claim  as  r  ee^oi  m ;•  del  than  w i t h  a  pre¬ 
claim  model.  hole,  however.  that  the  claim  as  reeded 
scheme  again.  produced  less  useful  1/0  arid  C P l T  utilizatior 
than  the  proclaim  model. 

However,  as  the  average  transaction  size  became  ever: 
smaller,  the  last  observatior  did  rot  hold.  With  ar:  aver¬ 
age  transaction  size  of  less  than  0.05'  of  the  database, 
random  data  access  patterns,  and  the  finest.,  granularity, 
the  claim  as  needed  scheme  resulted  in  greater  useful 
machine  utilization.  Under  these  conditions,  the  claim  as 
needed  strategy  allowed  the  greatest  concurrency  since 
locks  were  held  for  a  shorter  Deriod  of  time.  In.  contrast 
to  other  runs,  very  few'  transactions  had  to  be  backed  out 
and  the  cost  of  rerunning  such  small  transactions  was 
in  si gn i f ican t . 

The  modified  simulatior  was  also  rur  with  a  lock 
hierarchy  ar.d  various  threshold  percentage  values.  A 
similarity  in  the  shapes  of  the  curves  betweer  the  pre¬ 
claim  and  claim  as  reeded  st  ’’a  te  ie  s  was  also  observed. 
Under  the  random  access  a ssumot l : r s  ,  for  example,  the  max¬ 
imum  machine  utilization  was  again  reached  with  the  finest 
granularity  ard  a  threshold  value  of  1  to  ?  percent. 
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A  locking  hierarihv  should  be  implemented  when  the 
small  locks  are  of  a  fir.e  gr  an  ul  or  i  t  v ;  a  low  threshold  was 
used  to  separate  the  lnr^p  ar:d  sTall  trap  sac  tier  s ;  and 
rardo'n  data  access  uattorrs  were  anticipated.  Under  these 
assumptions  the  ir. crease  in  machine  utilization  over  a 
single  level  1  oc  k  1  n  g  scheme  was  significant.  Furthermore, 
a  threshold  of  about  one  percent  produced  the  best  results 
ir.deperder t  of  the  granule  placement  or  transaction  size 
assumpt ions . 

With  coarse  granularity,  or:  the  other  hand,  a  lockin'!’ 
hierarchy  was  not  beneficial.  The  benefits  of  such  a 
hierarchy  were  not  significant  and  were  only  realized  ir: 
certain.  cases.  Another  problem  with  the  coarse 
gr  ar.  ul  ar  i  t  y/ loc  ki  ng  hierarchy  model  was  that  the  optimum 
value  for  the  threshold  percentage  was  extremely  sensitive 
to  the  placement  of  the  locks  with  respect  to  the  transac¬ 
tions. 


The  acquisition,  of  locks  throughout  the  processing  of 
a  transaction  did  ret  significantly  charge  th«  other  cot  - 
elusions.  However,  several  observation  s  were  made. 
Deadlock  detection  ar  d  resolution  ar.n>«  ared  to  be  generally 
more  expensive  than  the  release  and  reroquert  used  in  the 
preclaim  strategy.  Thus,  when  locks  were  kr.cwr.  at  the 


Start  of  a  tm-  sacti  or  ,  ore,!  al  gc  r  i  ‘ 


s 


n.  cnv-'i.'ir; 


The  activity  and  rffoits  of  a  locking  'Vi.hr  i  r.m  were 
simulated  to  study  the  tradeoffs  between  increased  paral¬ 
lelism  of  concurrently  runnier,  tr  an  sac  tier  s  and  increased 
overhead  caused  by  sophisticated  and  complex  lockirr 
meohar  isms.  The  conclusions  of  the  study  are  first 
applied  to  physical  granules.  The  application  of  these 
results  to  predicate  lockir  g  is  then  discussed. 

K  Physical  Lockirg 

Under  the  assumptions  mentioned  in  the  description  of 
the  model,  in  many  cases  a  small  number  of  granules  is 
sufficient  to  allow  enough  parallelism  for  efficient 
machine  utilization.  Furthermore,  a  large  number  of 
granules,  corresponding  to  locking  a  page  or  record  is 
ofter.  extremely  costly. 

These  basic  corclusiors  are  due  to  the  fed  ’  c  wir  ~ 
observations.  For  large  transactions,  fire  grar  u ;  i  tv 
becomes  too  expensive.  A  transaction  which  accesses  half 
of  the  database,  for  example,  would  spend  ctrsiderabie 
resources  locking  each  page.  Yet.  little  pair  in  parallel¬ 


ism  would  he  realized  since  other  transactions  would  have 


a  strct  g  r>i- rh  i  ]  i  t  v  c  f  iorf1ut:rg  wi  1  r.  thrt  large  trar  - 
sac- tier  .  A  small  trar  sac  t.i  •  ?  wh  i  >.  h  ac».  esses  or  1  v  ore 
page,  or  thn  other  hard,  must  lc^k  s  ’nuvli  larger  g rar.ul  e . 
The  result  art  loss  in  parallelism  is  nir:  ini  zed  because  the 
small  trarsaetior  would  or.lv  hold  the  lock  for  a  short 
period  of  time.  The  probability  of  conflict  and  the 
length  of  any  waiting  period  would  rot  be  large  due  to 
that  short  period  of  time  that  the  lock  is  held. 

However,  there  are  corditiors  where  these  observa¬ 
tions  do  not  hold.  Details  of  which  eorditior.s  support 
which  level  of  gr an ul ar i ty  are  presented  below. 

If  equal  sized  lockable  granules  are  assumed,  a  small 
number  of  granules  (10  to  100)  are  sufficient  under  any  of 
the  following  corditiors: 

1)  The  locks  are  well  placed  with  respect  to  the  running 
trar:  sac  tier  s  . 

?)  The  number  of  entities  required  by  trar sac tiors  vary 
in  size  and  include  at  least  some  trar snetier s  that 
require  access  to  a  large  number  cf  er  titles. 

3)  Some  per  tic?  of  the  l.ckirg  sc  h^me  i  r  velvet,  extra  I/m 


Howov^r  ,  c.-'k  h  .f  the  fo-l  1  ~  fut  tr-  :  j»-  r.  ..rtr  some- 

what  finer  gran  ul  nr  i  tv  : 

1)  All  of  the  trnr  riictior  s  ire  extreme!  v  small  ar  d 
access  less  than  1%  of  the  database. 

?.)  The  length  of  time  that  locks  are  held  is  extremely 
lor.g  and  rot  Droportioral  to  the  size  of  the  transac¬ 
tor  ,  as  was  the  case  with  the  "idle  time"  experi- 
men  ts  . 

31  The  locking  costs  are  reduced,  for  example,  by  keen- 
in  g  all  locks  in  core. 

4)  A  balance  exists  between  the  I/O  resources  and  CPU 
resources  required  for  processing  a  trap,  sac  tier  . 

If  all  of  the  following  conditions  are  met,  the 

finest  granularity  should  be  used: 

1)  All  of  the  transactions  are  small. 

2)  The  locking  costs  are  reduced  by,  for  example,  keep¬ 
ing  all  locks  ir.  core. 

31  Random  access  patterrs  (or  worse)  are  exhibited  by 


the  tr  ar.  sac  tier  s  . 


However,  if  ccrditicr  1  is  v  jointed,  a  1  <,<.  k  hierarchy 
must  he  used  if  the  fine  granularity  is  still  to  be  sun- 
ported  . 

The  overall  coi clusior  is  thus  that  the  optimum  lock¬ 
ing  granularity  is  somewhat  applicatior  dependent.  In 
many  cases,  coarse  granularity,  such  as  file  or  relation 
locking,  with  a  proclaim  strategy  is  to  be  preferred.  In. 
other  cases,  somewhat  finer  granularity,  such  as  area  or 
extent  locking  is  best.  In.  still  other  cases,  the  finest 
granularity  such  as  page  or  record  locking  is  required. 

4.2.  Predicate  Locking 

Four  results  from  the  simulation  support  the  poten¬ 
tial  viability  of  predicate  locking.  Firstly,  with  predi¬ 
cate  locking  only  a  small  number  of  locks  must  be  main¬ 
tained  and  can.  probably  be  maintained  in  main  memory.  The 
number  of  locks  is  proportional  to  the  number  of  active 
trar.sac.tiors  and  rot  to  the  size  of  the  database. 

Secotdly,  while  predicate  locking  may  require  more 
CPU  time  per  granule  thar  Physical  locking ,  the  simulation 
results  irdicate  that,  for  coarse  gran,  ul  ar  i  t  v ,  some 
increases  in  locking  overhead  are  affordable  an  d  do  rot 
significantly  ir  ter  fere  with  trnr  sac  *  io  r  processing. 


Thirdly,  the-  parameter  \  >.  p  had  c  or  si  d^r  nb)  e  f  f e«..  t 
or  the  dosirr  i  r  inbor  of  ".rat  ul  or  ms  the  rubber  of  enti¬ 
ties  '  toiK  h--d  '  by  the  t  r  or  r."u  t ;  r  *  s.  As  the  trar  sactior 
size  decreased,  the  desired  rubber  of  granules  ir  creased . 
Note,  ir  predicate  locking  sc  hones ,  the  portior  of  the 
database  locked  is  determined  hy  the  trar:  sactior  ,  and  rot 
a  presoec  i  f  ied  qranul  ar  i  tv  ,  effectively  mimickir  r  the 
above  variable  nr  ar.  ul  ar  i  ty  . 

Fir  ally,  the  results  of  the  lock  hierarchy  simulatior 
m  i  q  h  t  indicate  that  a  simple  predicate  locking  scheme 
mip.ht  be  suf f icier.t .  It:  ore  such  scheme,  two  types  of 
locks  could  bp  sun  nor  ted.  First  an  er.  tire  r  el  at  i  or  , 
record  tyoe  or  file  could  be  locked.  The  small  locks 
would  be  based  or  a  simple  unique  key-value  pair.  The 
predicate  lockirq  scheme  could  easily  check  whether  a 
key-value  pair  corflicted  with  either  ar.  entire  relation 
lock  or  other  key-value  pairs.  The  lock  hierarchy  simula¬ 
tion  results  indicate  that  orlv  a  small  r umber  of  key  - 
value  nairs  would  have  tc  be  mairtair.ed  before  the  1 arqer 
style  lock  should  be  aunlied.  Furthermore,  the  simulatior 
results  indicated  that  subsettir  •-  the  trar  sac  tier?  tv  less 
dense  attributes  (ores  with  crly  a  hardful  of  differert 
values)  would  rot  be  bereficial  ir  a  lock  hierarchy. 
Thus,  in  these  cases,  keeoirq  the  predicate  locking 
mechanism  quite  simnle  would  be  justified. 
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However  .  such  ■<  si-v.-l  e  urn-lie  *  In  1  c i '  g  mec  hnr  :  om  is 
rot  very  d  1  f  f  er«r.  t  fVo:  3  simple  :hvsif".1  lock  h  i  er  arc  h  v  . 
For  example.  locking  ;  1  ■:  gi«.  r«l  i  elatior  '^iv  ir  some  imple¬ 

mentations  be  identical  to  1  ockire  a  physical  file  or 
area.  At  the  finest  grnr  ul  ~.r  i  tv ,  a  predicate  lock  of  a 
unique  key-value  pair  identifies  ore  record.  A  physical 
lock,  or  the  other  hard,  would  uniquely  identify  the  same 
record  by  a  physical  address.  Thus,  in  terms  of  parallel¬ 
ism  and  operation,  a  simplified  predicate  locking  scheme 
is  identical  to  a  physical  locking  scheme.  The  physical 
locking  scheme,  however,  may  be  easier  to  implement. 
Moreover,  the  physical  address  for  a  record  might  take  up 
less  space  in  a  lock  table  than  a  predicate  lock  for  the 
same  record . 

Another  problem  exists  with  predicate  locking.  Ir. 
some  applications,  a  seccrdarv  key  or  index  is  used  to 
access  a  given  record  type.  L'rder  the  simple  predicate 
locking  hierarchy  described  above  either  all  access  via  a 
primary  key  would  have  to  wait  for  the  seccrdarv  index 
appl icatior  to  complete;  cr  the  recc'd  would  have  to  be 
read,  the  key  value  obtaired,  nr d  th°r  a  lock  requested. 
Wher  the  lock  is  grnr  ted  tr.°  record  w  wld  have  to  be 
reread.  With  physical  leks.  cr  the  ether  hard,  the  phy¬ 
sical  record  address  woul  1  to  ur  i que  . 


f; 


Ir  summary ,  th'-r  ,  whi  1  <•  pred  is-  ate  3  •:  k i  r  •*  m a y  k 
viable,  it  rices  riot  seem  to  ho  worth  the  extra  imtlemer  t  ? 
tier:  and  locking  overhead,  because  it  car  c-rly  be  aonl  ie 
wher  specific  sets  of  the  database  r.eod  to  be  lcckir.r 
Furthermore,  those  cases  car.  be  handled  adequately  b 
similar  physical  locking  schemes. 


CHAPTER  3 


DISTRIBUTED  DATABASE  SYSTEMS 

1  •  introduction 

In  the  previous  chapter,  simulation  models  were  used 
to  investigate  the  performance  issues  of  concurrency  con¬ 
trol  in  a  centralized  database.  In  this  chapter,  those 
simulation  models  are  extended  to  study  the  performance 
issues  of  concurrency  control  in  a  distributed  database. 

1*1'  Distributed  Databases 

In  a  distributed  database,  the  data  is  stored  at  mul¬ 
tiple  computer  sites  connected  by  some  tyoe  of  computer 
network.  In.  this  environment,  a  transaction  originates  at 
one  of  the  computer  sites  and  potentially  accesses  data  at 
other  (or  remote)  sites  as  well  as  at  the  originating 
site. 

The  benefits  of  a  distributed  database  include  the 
ability  to  share  and  access  eecgr  a  nh  i  c.  a  1 1  v  distant  data, 
to  exercise  some  local  ccrtrcl  ever  subsets  of  the  data¬ 
base,  to  provide  m c  d  u 1  a r  growth  a r d  r e  s i 1 i e r c v  to  the 
database,  ard  to  increase  the  ootertial  parallel  is.m 
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allowed  i n  accessing  the  database. 
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1.2.  Pi str i huted  Database  Concurrency  Control 

The  distributed  concurrency  cortrol  mechanism  must 
guarantee  the  same  type  of  consistency  which  was  reeded  ir» 
the  centralized  database.  However,  the  performance  issues 
in  a  distributed  database  are  differ ent  than  in  a  central¬ 
ized  database.  This  difference  is  due  to  the  following 
f  actors : 

1)  More  parallelism  is  possible  because  multiple  sites 
can  simultaneously  process  transactions.  In  the  cen¬ 
tralized  model,  at  most  two  servers,  the  I/O  and  CP'J 
processors,  could  be  kept  busy.  In  an  N  site  system, 
there  are  2*N  servers  which  can  be  simultaneously 
processing  transactions. 

2)  The  overhead  associated  with  distributed  concurrency 
control  will  be  higher  than  the  overhead  required  in 
a  centralized  database.  The  additional  overhead  is 
due  to  the  costs  required  to  set  locks  at  remote 
sites  and/or  the  costs  which  may  be  required  to 
resolve  deadlock  between  trar sections  at  different 
sites.  The  remote  lockirg  overhead  is  due  to  the 
network  delays  involved  with  sending  and  receiving 
lock  messages.  The  deadlock  resol utior  overhead 


includes  the  computer  resources  required  to  detect 
deadlock  and  to  roll  back  certain  transactions. 

The  simulation  model  for  the  centralized  database 
concurrency  control  was  extended  to  investigate  the 
trade-offs  between  the  increased  parallelism  and  increased 
overheads  of  a  distributed  database.  The  major  areas  of 
study  include  the  effects  of  varying  the  locking  granular¬ 
ity,  varying  the  percentage  of  transactions  requiring 
non-local  or  remote  resources  and  varying  the  throughput 
and  bandwidth  of  the  network. 

In  the  next  section,  the  extensions  of  the  simulation 
model  which  apply  to  all  distributed  concurrency  control 
algorithms  are  discussed.  In  section  3,  four  different 
concurrency  control  algorithms  and  their  associated  simu¬ 
lation  extensions  are  discussed.  In  section  4,  the  simu¬ 
lation  results  for  each  of  the  four  algorithms  are 
reported.  In  the  final  section,  the  major  conclusions  are 
stated  . 

2.  MODEL  EXTENSIONS 

In  this  sectior  the  model  exter  sicr  s  are  described. 
First,  the  network  model  is  reviewed.  Next  the  acticrs  at 
each  of  the  nodes  or  network  sites  is  discussed.  Fir  ally, 
the  input  and  output  parameters  of  the  model  are  dis- 


97 


cussed.  Throughout  this  section,  only  the  processing  of 
transactions  will  be  considered.  In  the  next  section, 
four  concurrency  cortrol  algorithms  will  be  integrated 
in  to  the  model . 


?*!•  Network  Model 

The  network  is  considered  to  be  a  collection  of  com¬ 
puter  sites  called  nodes,  all  corrected  by  a  "logical  net¬ 
work  manager"  as  shown  in  figure  3-1.  This  manager  could 
represent  a  specific  star  like  network,  or  a  more  general 
node  to  rode  network  like  the  ARPANET  [KLEI76].  In  either 
case  it  is  assumed  that  the  time  to  send  a  message  between 
any  pair  of  nodes  is  the  same. 

Each  Node  contains  a  message-in  and  a  message-out 
queue.  Messages  are  taken  from  the  message-out  queue  and 
given  to  the  Network  Manager  together  with  a  destination 
and  a  message  length.  When  a  message  has  received  the 
needed  amount  of  network  service,  it  is  placed  on  the  des¬ 
tination  message-in  queue. 

Both  a  speed  and  a  bandwidth  are  associated  with  the 
Network  Manager.  The  network  speed  is  represented  by  the 
minimum  time  a  message  of  any  tvoe  must  soer d  in  the  net¬ 
work  where  time  is  measured  in  the  time  units  of  the  simu¬ 
lation.  The  bandwidth  is  represented  by  the  maximum 


Network  manager 


98 


NODE  0  NODE  N 


Figure  3-1:  Network  Model 


number  of  messages  which  can  be  serviced  in  ore  of  those 
time  units. 

The  flow  of  a  message  in  the  Network  Manager  can  be 
described  as  follows: 

1)  When  a  message  enters  the  network  manager,  the  time 
remaining  for  that  message  is  initialized  to  the  mes¬ 
sage  length  in.  the  time  units  of  the  simulation.  The 
message  length  can  vary  depending  on  whether  or  not 
data  is  being  sent  but  is  at  least  equal  to  the 
minimum  length  mentioned  above.  More  details  or  this 
length  are  in  section  2.3. 

2)  If  MESSBDWH  is  the  bandwidth  of  the  Network  Manager, 
the  times  remaining  of  the  first  MESSBDWH  messages  in. 
the  Network  queue  are  reduced  by  one  time  unit. 

3)  If  the  time  remaining  for  any  message  is  zero,  it  is 
delivered  to  the  message-in  queue  of  the  destination 
node . 

In  several  of  the  corcurren.cy  control  schemes,  a  site 
can  send  messages  to  itself.  In  these  cases,  ro  ret work 
resources  are  consumed  cr  network  delay  realized,  since 
the  message  is  taken  directly  off  of  the  message-cut  queue 
and  placed  or:  the  messag°-ir  queue.  However,  local  mes- 


100 


sage  costs  (CPU  time  spent  by  a  node  handling  messages) 
are  included  for  these  self-directed  messages. 

2.2.  Site  Model 

Each  site  or  rode  in  the  model  is  very  similar  to  the 
centralized  model  presented  in  Chapter  2.  However , 
several  new  queues  and  procedures  were  added  to  process 
distributed  transactions.  The  new  model  is  shown,  in  fig¬ 
ure  3-2.  Again  transactions  are  cycled  around  a  closed 
loop  model  and  initially  arrive  ore  time  unit  apart  on  the 
pending  queue. 

There  are  three  possible  types  of  transacti or s  in  the 
model.  First,  there  are  local  transactions  which  are 
identical  to  the  transactions  in  Chapter  2.  Secondly, 
there  are  MASTER  transactions  which  require  access  to 
parts  of  the  database  at  randomly  selected  other  rodes. 
The  MASTER  transactions  initiate  a  fixed  number  of  SLAVE 
transactions  at  those  other  rodes  via  messages. 

The  transactiors  go  through  the  following  steps:  1)  leave 
the  pending  queue,  2)  I/O  orocessirg,  3)  CPU  nroeessirg, 
*0  data  tr  an  sm  i  s  s  i  or-  ,  5)  local  processing  c omelet l c :  ,  ar  d 
6)  distributed  processing  syr.chrcr  i  ration  . 

1)  When  a  tr an  sac t i or  leaves  the  per  ding  queue  it  is 
placed  or  the  I/O  queue.  If  the  trar sactiot  is  a 
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Figure  3-2:  Node  or  Site  Model 


MASTER,  it  spp.ds  SLAVE  create  messages  to  the 
approoriate  nodes. 

The  I/O. server  is  multiplexed  amorp  the  transactions 
on  the  I/O  queue.  When  a  transaction  has  received 
its  share  of  I/O  resources,  it  is  placed  on  the  CPU 
queue  . 

The  CPU  server  is  multiplexed  amorp  the  transactions 
in  the  CPU  queue.  When  a  transaction  has  received 
its  share  of  CPU  resources,  its  next  action  depends 
or:  whether  or  not  the  transaction  is  local. 

Local  transactions  are  considered  complete  at  this 
point  and  recycled  to  the  perdinp  queue.  Non-local 
transactions  (both  SLAVES  and  MASTERS)  are  placed  or 
the  data  trar: smissior:  queues.  If  any  data  is  to  be 
trar smitted,  a  data  transmission  messape  is  sent. 
This  transmission  messape  is  in  fact  addressed  back 
to  the  sendirp  transaction.  Thus  the  data  trar.smis- 
sior  is  comnlete  when  this  messape  is  delivered  back 
to  the  oripir.  atirp  site. 

W  her  the  data  tr  ar  smi  ssior  messape  has  beer.  received 
(or  if  re  .data  was  to  be  trar  smitted),  the  rcr-  local 
trar  sa*.  tier  or  ec  ends  to  the  Network  dcre  queue.  At 
this  time,  SLAVE  trarsactiors  send  a  SLAVE  complete 


message  back  to  the  MASTER  trar.sactior  . 


6)  Depending  or:  the  concurrency  cortrul  strategy, 

SLAVE  either  waits  on  the  Network  dor e  queue  or  is 
simply  released.  The  release  of  a  slave  is  discussed 
in  more  detail  in  section  3.  The  MASTER  transactior 
waits  or:  the  Network  dor-e  queue  until  it  has  received 
"slave  complete"  messages  from  all  its  slaves.  At 
that  point,  the  trar.sactior  is  recycled  back  to  the 
pending  queue. 

Three  tyoes  of  messages  are  common  to  all  of  the  cor  - 
currency  control  algorithms.  The  ac-tiors  caused  by  these 
messages  are  described  below. 

1)  When  a  "SLAVE  create"  message  is  received,  a  transac¬ 
tion  identical  to  the  MASTER  transact ioi  ,  or  1 v 
flagged  as  a  SLAVE  is  added  to  the  pending  queue. 

2)  When  a  "  data  transmission  done"  message  is  received , 
the  waiting  MASTER  or  SLAVE  trar.sactior  is  r  c  t  i  f  i  e  d  . 

3)  When  a  "SLAVE  complete"  message  is  rec  ev.  ed ,  t  to'1 
ccrrespor  dir  g  MASTER  trar.sa.  t  i  rr  s  cr  the  twc  rk  i  c  r  •-> 
queue  is  rotified.  If  the  *'A  TER  trar  ra«.  tier  :  s  ret 
completed,  the  message  is  retried  t  .*•  t  he  message-  i  r 
queue  ur.til  the  MASTER  trar  sac  tier  c  car1.  n*  . 
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Several  simplifying  assumptions  should  be  noted  about 
the  model.  First,  all  of  the  SLAVEs  are  identical  to  the 
originating  MASTER  in  terms  of  the  proportion  of  database 
accessed  and  whether  or  not  data  is  to  be  transferred.  In 
distributed  database  applications,  the  actual  characteris¬ 
tics  of  the  SLAVES  could  be  quite  different  from  the  MAS¬ 
TER  and  f rom  each  other.  Second,  the  only  synchronization 
between  the  SLAVEs  and  their  MASTER  transaction  occurs  at 
the  beqir  r  iriq  and  end  of  the  transaction.  Some  applica¬ 
tions  would  require  additional  synchronizations  or:  the 
data  beinq  transmitted  [W0NG77,  FPST78 ] . 

Also  rote  that  a  transaction  is  or:  each  of  the  I/O, 
CPU  and  data  transmission,  queues  once  in  the  indicated 
serial  order.  The  total  processing  required  is  the  same 
as  if  the  transaction  cyclically  accessed  the  I/O,  CPU  and 
data  transmission  queues. 

2.R.  Model  Parameters 

The  incut  parameters  <.  an  be  divided  into  the  parame¬ 
ters  teat  characterize  the  workload,  the  svstem  parameters 
that  characterize  the  ir dividual  r  odes ,  ard  the  parameters 
that  characterize  the  network .  The  workload  parameters 
d e t e r -  i r  e  the  database  ard  the  trar. sactiors  that  are  r u r. 
aqairrt  that  database.  As  ir.  Chapter  2,  the  system  param- 
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eters  determine  the  computer  and  database  mar:  agcner  t  sys¬ 
tem  characteristics.  The  network  parameters  include  the 
minimum  time  required  for  messages,  the  network  bandwidth 
and  the  CPU  and  I/O  resources  required  for  processing  mes¬ 
sages  at  each  site. 

The  output  measurements  include  the  overall  CP'J  arc 
I/O  resource  utilizations  for  transactions ,  messages  and 
concurrency  control  as  well  as  network  measurements. 

These  parameters,  in  most  cases,  have  the  same 
interpretation  as  in  Chapter  2.  All  of  the  parameters  are 
described  in  detail  below. 

2 . 3 . 2 •  Workload  Parameters 

The  workload  parameters  desc  ribe  the  transact  icts  ard 
the  portion  of  the  database  at  each  node.  Table  sum¬ 

marizes  the  workload  parameters. 

The  first  five  parameters  are  identical  to  the  param¬ 
eters  discussed  in  Chanter  2.  For  almost  al  1  of  t 
experiments  reported  in  this  chanter  or  lv  3  few  s-t-,  :r  • 
of  those  parameters  are  used.  The  efforts  of  v  ;rv'.*  a 
those  parameters  would  be  similar  tc  the  effects  r«:  .  rt-  : 
ir.  Chanter  2. 

In  particular,  UTP't’J  was  set  tc  10  simul  a t i •  r  10 
transactions  rurring  at  each  node.  Thr  Dhfl/F.  at  each 
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Table  3-1 

Workload  Parameters 


Parameter  Description 

Local  Parameters 

NTRAfl  Number  of  transactions  running  at  each  node 

DBSIZE  Size  of  the  portion  of  a  database  at  a  i*iven  node 
AMEAN  Low-mean  of  exponential  distribution, 
for  transaction  size 

BMEAN  Hif»h-mear  of  exponential  distribution 
for  transaction  size 

ALPH  Cut  point  for  Hyoer-expor.  ential  distribution 
for  transaction  size 
LKPLMT  Lock  Placement  assumption 

Distributed  Parameters 


PREDIST  Percentage  of  transactions  which  are  non-local 
PRETRAN  Percentage  of  distributed  transactions 
which  transfer  data 

PREDATT  Percentage  of  data  transferred  by 
those  distributed  transactions 
NSLAVES  Number  of  SLAVES  for  a  distributed 
transaction. 


node  was  set  to  10,000,  resulting  in  a  total  database  size 
of  10,000  times  the  number  of  nodes  in  the  network. 

Two  classes  of  transactions  are  modeled.  With  class 
one  transactions,  the  transaction  sizes  vary  considerably 
and  the  locks  are  assumed  to  be  well-placed  with  respect 
to  the  accessir ?  transactions.  For  these  transactions 
AMEAN  is  5,  P'lE-W  is  ?50  and  the  ALPH  Dsrameter  was  set  to 
.1.  This  class  cf  transact  ions  simulates  a  workload  where 
most  (90")  cf  the  transactions  are  small  (they  access  0.^5 
percent  cf  the  database)  and  a  few  cf  the  transactions  are 
lar^e , 
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With  class  -two  transaction  s  ,  all  tr  ar  sue  t  i  oi  s  arc 
small  and  the  placement  of  the  locks  is  assumed  to  be  ran¬ 
dom  with  respect  to  the  accessing  tr an  sac t i or  s . 

The  remaining  parameters  deal  with  the  non-local 
transactions  and  are  the  ones  of  most  interest  ir  this 
chapter.  The  proportion  of  transactions  which  are  MAS¬ 
TERS,  the  PREDIST  parameter,  determines  the  number  o  f 
tr  an  sac  ti  or  s  at  each  node  which  require  processirg  at  som--* 
other  site.  Experiments  were  run  with  PEEDTST  settings  of 
0,  10,  25,  50,  75  and  100  percent. 

The  number  of  SLAVES  required  by  a  MASTER  are  ioter- 
mined  by  the  KSLAVES  parameter .  The  orir.it  al  number  of 
database  entities  required  by  the  MASTER  is  evenly  distri¬ 
buted  among  the  SLAVES  and  the  MASTER.  Thus,  if  the  MAS¬ 
TER  originally  requires  E  of  the  database  en ‘ i 1 1 o s  ,  at 
each  site  where  the  transaction  was  active . 
E/(NSLAVES  +  1),  entities  are  actually  accessed. 

The  amour  t  of  data  to  be  tr.ar  sferred  is  dotermirod  by 
the  PRPTRAN  ar  d  PREDATT  parameters.  The  P  "  T A  b  par  ter 
determines  the  r  umber  of  d  l  str  ibuto  i  t  r  ar  ra,  *.  :  *  ••  i 
transfer  ar  v  data  at  all.  The  PR"'  ATT  r  ar  -r  i.-.t  er¬ 
mines  hew  mar y  of  a  transaction's  entities  will  b a v e  *:  r-? 
transferred.  The  number  of  entities  tr&?  sf«rre  i  :«t  er¬ 
mines  the  1 e  r  r t  h  of  a  data  trarsfer  message  a  n  1  h  e  r  v  e 
determines  hew  long  a  transactin'*  soerds  or  t  he  tb-t  w.  iv 
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wait  queue. 

In  summary,  the  database  consists  of  a  collection  of 
entities  at  each  node.  Each  transaction  "touches"  or 
accesses  a  certain  number  of  those  entities.  Some  of 
those  transactiors  require  access  to  entities  at  remote 
nodes.  Furthermore,  some  of  those  transactions  will  have 
to  transfer  data  between  nodes. 

2.2.2.  System  Parameters 

The  system  parameters  describe  the  computer  system  or 
database  system  at  each  node  and  are  very  similar  to  the 
system  parameters  of  the  centralized  database  model 
described  in  Chapter  2.  The  system  parameters  are  summar¬ 
ized  in  Table  3-2. 

The  NGRAN  parameter  is  the  number  of  lockable 
granules  at  each  node  of  the  distributed  database  and  is 
identical  to  the  'JGRAN  oarameter  of  Chapter  2.  The  oaram- 

Table  2-2  System  Parameters 
Parameter  T escr  i  rt  i_ot 

NGRA’.'  number  c-f  lockable  urits  of  ere  node 

of  the  database 


CPUR  ME 

C  PM 

time 

to 

pr  c-c  ess 

ere 

er  t  i  t  v 

I  o  >■  A  T  E 

I/O 

time 

to 

or  ;.cPS  s 

cr  e 

er  ti tv 

LCP  If. ATE 

CPU 

time 

tc 

process 

or  e 

leek 

LI  OR  ATE 

I/O 

time 

to 

process 

ore 

1  cc  k 

eter  was  varied  from  1,  rcpresertirr  or  e  lov.k  at,  eat  n 
node ,  ud  to  DBSIZE,  represer.  ti  nr,  ore  lc.v.k  per  entity  lr 

the  database. 

The  CPURATE  and  IORATE  determine  the  cost  to  process 
one  entity  in  the  datahase  and  are  also  icier,  tical  to  the 
parameter  in  the  centralized  database  model.  For  these 
experiments,  the  CPURATE  and  TORATE  were  both  equal  to  ' 
time  unit.  This  scenario  simulates  a  system  with  a  bal¬ 
anced  load  between  the  CPU  and  I/O  requirements.  Also 
under  this  scenario,  ore  time  unit  of  the  simulnt.io:  car 
be  thought  of  as  the  time  required  for  ore  I/O  operatior  , 
i.e.,  about  30  milliseconds. 

The  LCPURATE  ar.d  LIORATE  parameters,  the  costs  to  set 
and  release  ore  lock,  are  also  identical  to  the  parameters 
in  the  centralized  database  model.  For  these  exnerimer  ts, 
the  lock  CPU  rate  was  ore  tenth  the  entity  Cpu  rate  ,  :.f  .. 
0.1.  Under  the  scenario  mer.tiored  above,  this  miqht 
represent  3  milliseconds  to  set  ar  ,i  role  ?sc  a  leak.  The 
LIORATE  was  zero,  simulati  r  •’  a  system  where  all  1  are 

kept  i  r.  main  memory. 

Note  that  NOR  Ah,  L0P'’-A7E.  LIORATE  ar  r  t.E7".  VT  (  fr  - 


the  previous  sec-tior)  are  1 
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of  the  cor  currer  c  v  ccr  tr  - 1  al  e  :  r  i  • :  h“  s  .  As  d  :  t  i  or  al  oar  r  -  - 
ters  relevant,  to  the  individual  or  r  currer  c  v  ccrtrcl  algo¬ 


rithms  are  introduced  ir  the  seotior  d e sc- r i hi r  q  th 
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algorithms. 


2.3.3.  Network  Parameters 


The  network  parameters  determine  the  throughput  and 
bandwidth  of  the  network  as  well  as  the  CPU  resources 
required  at  each  site  to  send  and  receive  a  message.  The 
network  parameters  are  summarized  in  Table  3-3. 


The  number  of  nodes  in  the  network,  set  by  the  NNODES 
parameter  was  varied  from  two  to  eight. 


The  message  rate  parameter,  MESRATE,  is  the  length  of 
time  it  takes  to  send  a  simple  message  (i.e.  a  non-data 
transfer  message)  from  one  node  to  another.  Typical 
values  for  this  parameter  ranged  from  1  through  10.  A 
value  of  3,  for  example,  would  represent  a  high  speed  net¬ 
work,  where,  under  the  interpretation  mentioned  in  the 
previous  section,  it  would  take  about  90  milliseconds  to 
Table  3-3  Network  Parameters 


Parameter 


Descr i pt  ior 


NNODES 

MESRATE 

DATARATE 
MES  5  n',.,!T 

MES IDEATE 

MESC^'JEf-TE 


The  number  of  nodes  or  sites  in  the  network 
The  time  units  a  message  must  stay  or  the 
network 

The  time  units  to  transfer  an  entity 

The  number  of  simultaneous  messages  cr 

bandwidth  of  the  N  e  t  w  o  r  k  a  r  a  g  e  r 

The  I/O  time  required  by  a  node  to  serd  or 

receive  a  message 

The  CPU  ti^e  required  by  a  rode  to  ser A  or 
a  message. 


receive 


deliver  a  message.  A  value  of  10  implies  it  would  take 
about  300  milliseconds  to  seed  a  message,  about  the  time 
required  or  the  ARPANET  (KLEI761. 

The  DATARATE,  together  with  the  MF.SRATE  parameter, 
determines  how  lorg  a  data  trar smissior.  message  will  take. 
If  E  is  the  number  of  entities  to  be  transmitted,  then  the 
data  transmission  message  would  take 

MESRATE  +  E  *  DATARATE 

time  units  to  be  delivered.  If  an  entity  is  a  512  byte 
page,  and  an  ARPANET  like  file  transfer  at  50,000  bits  per 
secord  is  assumed,  it  would  take  about  0.1  seconds  to 
transfer  1  entity.  On  the  other  hand,  or  a  three 
megahertz  speed  network,  it  would  only  take  about  .0015 
seconds.  Many  of  the  simulation  exDerimerts  used  and 
"optimistic"  DATARATE  of  .05  time  units.  Other  simulation 
experiments  used  DATARATES  of  .1,  .25,  and  .5.  The  MES¬ 
RATE  term  is  included  in  the  above  time  to  represent  the 
initialization  message  which  often  must  precede  a  network 
data  transmission. 

The  MESBD'VT  parameter  determines  the  bandwidth  :  f  the 
network  manager.  As  explained  in.  section  2.2,  at  most 
MESBDWT  messages  in  the  network  queue  are  serviced  ea>.  h 
time  unit.  For  lightly  loaded  retworks,  it  is  reasonable 
to  assume  that  the  bandwidth  is  unbounded  [‘<LEI76]  and 
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tmt  a  s"  umnl  i  cr.  i  s  ir  fact  m  a  d  o  it  'nest  of  the  simulatior. 
ex  per  imer  ts  .  The  results  of  varvirg  that  parameter  are 
also  presetted. 

The  MESIORATE  and  MESCPPPATF.  parameters  represent  the 
resources  required  at  each  rode  to  send  or  receive  a  mes¬ 
sage.  For  these  simulatior  results,  the  MELIORATE  was 
zero,  simulating  that  the  orocessir  of  all  messages  is 
handled  ir:  the  main  memory;  and  the  MESCPURATE  has  a  value 
ranging  from  .01  to  .3  time  units;  or  ir.  the  canonical 
i  r.  ter  nr  o  t  a  t  i  or  from  .3  to  9  mil  1  i  secor  d  s  .  For  the  most 
part,  the  lower  bound  or  MESCPURATE  was  used,  simulating  a 
very  low  (and  optimistic)  overhead  message  processor. 

2.3-^.  D ar ameter s 

The  quartities  to  be  measured  cr.  the  output  parame¬ 
ters  are  summarized  ir.  Table  3-^.  These  measurements 
include  all  of  the  measurements  included  ir.  the  central¬ 
ized  database  simulatic-r  and  some  other  parameters  unique 
to  th, a  distributed  model. 

The  first  eight  output  parameters  are  identical  to 
the  output  parameters  discussed  ir  Charter  2.  The  TCPU 
and  TIC  parameters  refer  to  the  r  umber  of  simulatior  time 
units  dur ir  •-  which  the  CPU  arm:  I/I'  servers  for  all  of  the 
network  rod es  were  went  busv.  The  LQCKCPU  and  LOCK  10 
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Table  < ~ w 


1  1 

■  : '  :  1  it  :  , >•”<••  t  •"> r 
Parameter  Desor  : 

Loc-  al 

TC.PU 
TIO 

LOCK  C  P'J 
LOCK  I  0 
TRANCOM 
AVtiRRKS 
USLPULCPLJ 
USEFUL  10 

Distributed 

MESCPU  CPU  overhead  for  r  otwr rk  mossmces 

M P'S  10  I/O  overhead  for  r  o t w*  t  k  inssn  tc*s 

TMF.SS  The  total  number  of  a^ssia-o  ?.jr  t 

LMF.SS  The  r.umhcr  of  Loc  k  re  !  a  ted  m  e  s  s  a  ~  s  s.-rt 

parameters  refer  to  the  number  of  time  ur  its  thrt  rt!Sp<\ 

tive  servers  were  busy  mar- ar,  i  r:<t  looks.  The  TRAt'CC’-’  naram 

eter  is  the  total  r  umber  of  transactions  ecmoletoi  at  th 

end  of  a  simulation  rur  .  Note  that  a  distributed  *  ■  :'u 

tier’,  regardless  of  the  number  of  ccrresorr  i  i  r  *  'LAY 

tr ar.sacticr  s  ,  is  counted  as  oi  e  trar  sect  i-.  r  .  The  AYLPLP 

parameter  measures  the  average  number  of  time  ur  its  i 

takes  for  a  trar  sat  tier  to  «.  .mr  1  •'>1  •• .  For  d  i  . 

tr  nr  sac  t  i or  s  ,  the  ressrr  1 1  •>  ref-:--  s  t  r 

erc-e  between  wher  a  *.ST~R  t’'v  on.  *  i  -  >  ♦  .  -  r t  •  •  ••  •  f 

per  d  ir  m  queue  ar  d  wher  that  tr-.-r  r  ;  t ;  -  r  le.  ,.-r  t  •  •»  •  •  v  w.  r 

do re  queue. 

The  useful  ccm  r  iter  it  i  1  :  .■ a  t  .  -  r  -  .  ''rP  Pf 


Total  time  t.to  CP"  rv-'-r  was  a,  •;  v 
Total  time  t(r*  T  /•’  server  was  <k  l :  ve 
CPU  overhead  f  r  1  »,  1 :  i  r  ; 

I/O  overhead  for  IcoVir  ■’ 

Number  of  trar  r.u  ti  •,.!  s  o.  ■m,'l  ete-i 
Aver  a  r,  e  resort  se  time 
CPU  time  for  ore-,  essir  ••  trar  sect:  •  r> 
1/0  time  for  processir  -  trar  ••■u  t  i  r  r 


US'FULIO  , 


refer’ 


to  the 


resourv. 


;  r  r>  - 


processi n g .  These  measurements  were  not  used  for  con¬ 
currency  control  or  for  message  processing.  Note  that 

TCPU=USEFULCPU+LOCKCPU+MESCPU 

TIO=USEFULIO+LOCKIO+M£SIO. 

The  MESIO  and  MESCPU  parameters  refer  to  the  time 
required  by  the  I/O  servers  and  CPU  servers  at  the  various 
nodes  to  process  messages.  Note  that  a  message  must  both 
be  sent  and  received,  so  that  the  I/O  and  CPU  costs  to 
send  n  messages  are  r*2*MESI0RATE  and  n*2*MESCPURATE 
respectively.  This  cost  is  also  independent  of  the  mes¬ 
sage  length.  Thus,  for  a  data  transfer  message,  this  cost 
represents  initial  set  up  costs  to  actually  transfer  data 
to  the  network.  No  additional  local  costs  for  the  data 
transfer  are  incurred.  In  some  systems  considerably  more 
overhead  would  be  incurred  for  data  transfer. 

The  TMESS  Darameter  represents  the  total  number  of 
messages  sent  over  the  network.  The  LMESS  oarameter  is 
the  number  of  those  messages  which  were  sent  only  for  con¬ 
currency  control  reasors.  The  messages,  called  'Lock' 
messages,  are  discussed  when  the  cor. currency  control  algo¬ 
rithms  are  introduced. 
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2.4.  Typical  Sc-erarios 

The  simulations  were  ruri  with  the  parameter  settings 
shown  in  Table  3-5.  The  local  parameters  are  identical  to 
the  parameters  in  the  centralized  database  simulations  and 
for  the  most  part  were  rot  varied.  The  initial  settings 
of  the  distributed  parameters  are  designed  to  study  the 
concurrency  control  algorithms  under  a  basically  free  arid 
unlimited  network.  Later  alternate  parameter  settin.es  are 
used  to  study  the  effects  of  network  limitatiors  or  the 
different  concurrency  control  algorithms.  The  results  of 
those  experiments  are  reported  in  section  4. 

In  the  next  section,  the  four  concurrency  control 
algorithms  simulated  are  described  and  additional  parame¬ 
ters  required  for  those  algorithms  are  introduced. 

3.  DISTRIBUTED  CONCURRENCY  CONTROL 

The  distributed  database  eerourrercy  cor trol  algo- 


rithms  car  be 

divided 

into  two 

g  o  r  e  r  a  1 

c  las 

site 

concurrency 

cc r trol 

[  A  L  ?  B  7  5  , 

y E  N  A  7  R  1 

ar  d 

ized 

corcurrer  cy 

c  c  r  t  r  c  1 

r  q  rn>  - 7  ■? 

ELLI  7” , 

0  p  A  Y 

In  the  primary  site  cor  currer  cy  cc  r  trol  sc  hem  or  f:r  -• 
distributed  database,  ore  site  is  chosen  to  er  fence  a  rr_- 
cessir.g  schedule  equivalent  to  a  global  s*»r  ializnr  i  :r  :  f 


Table  3-5  Typical  t,’ir'.T:oter  Settings 


Par  a  m  «■>  t  <•  r 

S  0 1 1  i  r  r 

Local 

I  r  t.PM'i  '' t  at ;  0 1 

NT  RAN 

10 

10  trap,  s  at  each  rode 

DBS  I 7  f 

1 0 , 000 

10,000  database  entities 
at  eai. h  rode 

AM  FAN 

5 

0.05%  of  DBS I ZE 

BMP  AN 

250 

2.5%  of  DBSIZE 

ALP!! 

.  1 

10%  of  trar.s  are  lar^e 

0 

All  trar.s  are  small 

LKPLMT 

1 

Well-nlaced  locks 
(used  with  ALPH  =  .1) 

2 

Randomly  placed  locks 
(used  with  ALPH  =  0) 

CPU  R  AT1' 

1 

30  msecs 

IORATE 

1 

30  msecs 

LC  PUR  ATE 

.  1 

3  msecs 

LIORATE 

0 

Locks  in  main  memory 

Distributed 

PREDIST 

.  1 

10%  of  the  transactions 
are  distributed 

PRETRAM 

.  40 

40%  of  those  require  data 
tr an  sf  er 

PREDATT 

l r> 

CM 

25%  of  entities  touched 
by  the  transactors  are 
in  fact  transferred 

NSLAVES 

5 

A  distributed  transaction 
runs  at  all  nodes 

NNOD-.S 

6 

Six  rodes  ir  the  network 

MFSR ATr 

3 

His h  speed  retwcrk 

DATA.  RATE 

.  05 

fast  data  trar.sfer  Network 

>/  r  5; 7 

00 

Lightly  loaded  ret work 

MRS  I OR  ATE 

0 

Messages  bardie''  i  r  c  0  r  r 

MESS  PUR  ATE. 

.01 

.3  msecs  (very  rrtmistt. ) 

all 

of  the 

t r a r  s a c t. i c. r  s  rur  r  ir  a  at 

all  sites. 

Two 

stra 

i " h t  f or w a r 

d  i  m  r  1  em  er  tat  0  r  s  of  a 

d  r :  m  a  r  y  s 

i  te 

model 

are 

tr eser ted 

ir  sectors  3-1  ard  3.2- 

Basical  1 

*  » 

if  a 

prim 

a r  v  site 

handles  all  c or curr ore \ 

•  c.or  trol  , 

the 

same 

algorithm  used  for  a  cet.trali7.ed  database 


car  be  used  for 


the  distribute  d  a t n  h  n  r: ■  ■  . 


In  the  decor  tr  al  i  •/*■»■!  c  c.r  ^  error  cv  c.t’r'.l  sc  :•»' 
each  site  maintains  its  o«r  leeks  for  that  silo'  -  p  -  >  si: 
of  the  database.  However,  a  dead  lot  V.  i  c:  is  !  :  r  *  re  i 
can  exist  ir:  the  network  ever,  though  r.o  dea'il  ■' ck  i  yd 
exists  at  any  giver;  node.  For  example  Trar  tier  1  ca 

be  blocked  at  node  i  by  Trar. so.  tier  ? ,  At  ro  *.<■  ,  h.  w 
ever,  Transaction  2  can  be  blocked  by  Trar  sad.  in*  1 
Although  no  deadlock  exists  at  either  rode  i  or  i,  roithe 
Transaction  1  r.or  Tran  sac  tier  ?.  car  be  c  ompl  odd  .  Tv 
mechanisms  and  their  simulation  imnlemer.totioi  r  far  ion’ 
irg  with  this  deadlock  problem  are  presetted  it  sec  tisr 
3.3  and  3d. 


3.1.  Primary  Site  Model  1 


The  concurrency  cor  trol  mechanisms  ir  both.  the  pri 
mary  site  models  require  the  following  charges  to  the  rod 


model  shown  ir:  figure  3-2: 


When  ar  y  trar. sac  tier  (  Ucsl  :  r 
per  dir  g  iueun  ,  a  rich*1  Irek  re 


node  selected  as  the 


ther  waits  r 


‘  .  ’  \  f?  ’  .3  0  ,  4  n  7  ]_ 


until  all  of  its  1  c  <.  k s  > *- r t  •. • 


KVa*  ■ 


2)  When  a  global  lock  grant  is  received,  the  transaction 
can  proceed  to  the  I/O,  CPU  and  data  transmission, 
queues  as  before.  At  this  time,  a  MASTER  transaction 
starts  its  correspond ing  SLAVE  transactions . 

3)  Upon  receipt  of  a  "SLAVE  create"  message,  a  new  tran¬ 
saction  identical  to  the  MASTER  transaction  is  placed 
directly  on  the  I/O  queue. 

*0  As  in  section  2.2,  a  MASTER  transaction  waits  or.  the 
Network  done  queue  until  it  has  received  "SLAVE  com¬ 
plete"  messages  from  each  of  its  SLAVEs.  At  this 
point,  a  MASTER  transaction  sends  a  "global  lock 
release"  message  to  the  PRIMARY  site  and  is  recycled 
back  to  the  pending  queue. 

5)  In  the  PRIMARY  site  model,  a  SLAVE  transaction  reed 
rot  wait  or  the  Network  done  queue;  it  car.  simply 
send  its  "SLAVE  complete"  message  and  leave  the  sys¬ 
tem  . 

Note  that  the  "global  lock  request",  "global  lock 
grant",  ar.  d  "global  lock  release"  messages  are  all 
included  in  the  lock  message  court.  Also  rote  that  the 
"global  lock  request"  in  eludes  t.h?  lock  requests  for  all 
of  the  SLAVEs. 


In  the  primary  site  model,  the  nodes  are  considered 
to  be  numbered  zero  through  NNOPFS  -  1,  For  each  node , 
there  is  a  "blocked"  queue  and  a  "locks  held"  queue  as 

shown  in  figure  3-3. 

When  a  "global  lock  request"  is  received,  the  PRIMARY 
site  lock  controller  goes  through  the  following  steps: 

1)  Determine  which  nodes  will  be  used  by  the  requesting 
transaction . 

2)  For  each  node,  i  =  0,...,NN0DES  -  1,  see  if  this 

transaction  requires  locks;  if  not,  proceed  to  the 
next  node.  If  so,  request  the  locks  (identical  to  a 
lock  request  in  Chapter  2)  required  at  this  node. 

3)  If  the  locks  are  granted,  record  this  fact  or  the 

"locks  held"  list  for  rode  i  ar.d  repeat  step  2  for 

nodei+1  . 

4)  If  the  locks  are  denied,  Diace  the  trar  saltier  or  the 

blocked  queue  for  node  i,  recc-rdirg  the  bl  kir  .t 
trar.sactior  which  is  or  the  "locks  held"  aueuo  frr 

this  node, 

5)  Wher  the  locks  at  all  of  the  required  redes  are 

granted,  a  "global  locks  gr artel"  message  is  sort  ‘  - 

the  originating  site. 


Figure  3-3: 


When  a  "global  lock  release”  is  receive!,  the  p  H I M  A  R  Y 
site  lock  controller  removes  the  correspor  iinir,  trar.  r.'n  ti'-r 
from  each  of  the  "lock  held"  queues.  Ary  trar sootier 
which  was  blocked  at  node  i  by  this  trar sootier  is  res¬ 
tarted  at  step  2  for  node  i,  in  the  above  algorithm. 

The  following  ob ser v at  ion s  should  be  noted.  First, 
deadlock  is  impossible,  since  the  locks  at  the  different 
sites  are  always  acquired  in  a  fixed  order.  Sec  or d,  LOCAL 
transactions  will  only  be  involved  with  locks  at  their 
originating  sites.  Third,  note  that  a  non-local  transac¬ 
tion  can  wait  for  locks  at  ore  node  while  holding  looks  at 
a  lower  numbered  node. 

All  of  the  locking  costs  are  absorbed  by  the  primary 
site  which  also  has  a  normal  load  of  transaction  process¬ 
ing.  The  use  of  the  CPU  and  I/O  servers  by  the  primary 
site  control  mechanism  has  a  preemptive  priority  over 
transaction  processing  requests.  In  other  words,  if  there 
are  global  lock  releases  or  requests,  the  PRIMARY  site 
first  has  to  serve  those  requests  before  it  car  process 
any  trar,  sactior  s .  If  serving  those  requests  t  i-m-s  m:  re 
than,  ore  simulation  time  unit,  no  trar.  sac  ti;r  pr:o.essirm 
takes  place  during  that  time  urit. 
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3.2.  Fri_ma_ry  Site  Model  2 

The  activities  at  each  site  of  the  distributed  data¬ 
base  are  identical  ur der  this  model  and  the  previous  pri¬ 
mary  site  model  described  above.  The  only  difference  in 
the  two  models  occurs  in  the  Primary  site  lock  control. 
In  this  model,  there  is  only  ore  blocked  queue,  although 
there  is  a  'locks  held'  queue  for  each  node. 

When  a  "global  lock  request"  is  received,  the  PRIMARY 
site  lock  controller  goes  through  the  following  steps: 

1)-3)Same  as  in  previous  primary  site  model. 

*0  If  the  locks  are  denied,  release  all  of  the  locks 
held  for  lower  number  nodes,  record  the  blocking 
transaction  and  place  this  transaction  on  the  single 
blocked  queue. 

5)  Same  as  ir  the  previous  primary  site  model. 

When  a  "global  loci':  release"  is  received,  the  PRIMARY 
site  ccrtrcllor  again  releases  the  locks  held  at  each 
rode.  Ary  tr sr  ssetior  which  was  blocked,  is  restarted  at 
step  1  cf  the  above  algorithm. 

This  node!  differs  from  the  previous  model  in  two 
ways.  The  mair  difference  is  that  no  transaction  car  hold 


1  ; '  •: 

locks  at  ore  rode  while  wnitirg  for  locks  fro-  ar  other 
r:ode.  This  difference  "to  nr  5  that  trnr  sac  tier  s  requ  j  r  ir  a 
fewer  number  of  nodes,  (i.e.,  local  tr  ar.  sac  t.  i  or  s )  have-  nr 
implicit  priority  over  transactions  requiring  loc  k<-  at 

more  nodes. 


3.3.  Wound- Wa it  Model 

As  previously  mentioned,  decer’ tral  i  zed  cc.r  currency 
control  requires  a  mechanism  for  resolving  deadlock.  Ir: 
this  section  an  extension,  of  a  "wound-wait"  scheme 
[ROSE77]  for  resolving  deadlock  is  discussed.  First  the 
original  algorithm  in  [ROSF77]  is  presented,  followed  by 
two  extensions.  Finally,  additional  charges  ir:  parame¬ 
ters,  relevant  to  the  "wound-wai t"  algorithm  are  reviewed. 


3. 3. 2*  Original  Wour d-Wa i t  Algorithm 


In  [ROSF77],  the  trar.sactior  model  is  slirhtly  dif¬ 
ferent  than  the  ore  presented  ir.  this  chanter.  A  trar  sec¬ 
tion  is  viewed  as  a  prcc«ss  which  is  iritis-tod  a*,  .re  r:i- 
and  moves  from  rode  to  rode  ir  the  course  of  its  r^oc  or-?, 
ir.g.  At  any  ir.  star  ce  the  process  is  cor  si  der  ed  a.,  toco  s' 
or.*  node  ar.d  ir  active  at  all  other  :  odes  that  : t  h  ; 


visited. 


Ur. dor  the  wo ur  i i  t  algct  ithm,  a  unique  number, 
as  sirred  to  each  prc-coss  or  li-ar  sactior:  ,  is  obtained  by 
cor  c  a  ter  at  i  r.  g  a  startin’  time  with  the  node  number  at 
which  the  process  is  initiated.  (The  algorithm  does  not 
require  that  the  clocks  which  generate  the  time  stamps  be 
perfectly  synchronized.  However  ,  some  close  correspon¬ 
dence  with  the  "real"  time  would  be  desirable.  In 
[LAMP77],  a  sufficient  algorithm  for  keeping  clocks  at 
nodes  in  a  network  reasor  able  synchronized  is  presented.) 

Suppose  Tran  sac  tier  1  requests  locks  held  by  Trar.sac- 
tior  2  ar.d  that  timestamp  1  and  timestamp  2  are  the  unique 
numbers  associated  with  the  two  tran saetior s .  Then  the 
following  steps  are  taker:: 

1)  If  timestamp  1  <  timestamp  2,  then  Transaction  1  is 
"older"  thar  Transaction  2.  In  this  case,  Transaction 
2  is  wounded  and  Transaction  1  waits. 

2)  If  timestamp  2  <  timestamp  1,  then  Transaction  2  is 
"older"  thar  Trar  sac-tier  1.  Ir.  this  case.  Transac¬ 
tion  1  simply  -..aits. 

If  Trar.  sac  tirr  2  is  wcu:  del,  a  messare  is  ser  t  tc  all 
si  te  r  visited  by  Trar  2  .  If  termer  at  icr  :f  Trar  - 

s  a  c  t  i :  r  2  has  al read  y  h  •  j  r  ,  t  r,  e  wour  1  is  igr  cred  ,  sir.ee 
Trar  sac  tier  2  will  see:  release  its  leeks  ar  d  Transact icr 


1  sb 

1  car  proceed.  -If  Tran  sac  t  ior  2  has  not  be.'ut  trie  term  i- 
natior  process,  it  is  aborted  (or  killed)  ar.d  restarted. 
Again,  the  locks  held  by  Trar.sactior  ?  are  released  ar  d 
Transaction  1  can  proceed.  Note  that  in  order  to  prevert 
cascading  abortions  of  trar.sactior  s ,  all  locks  for  a  giver: 
transaction  are  held  until  that  trar.sactior.  terminates. 

A  natural  modification  to  this  algorithm  is  suggested 
in  [ROSE77],  where  Transaction  2  is  rot  aborted  ar  i  res¬ 
tarted  unless  it  is  actually  in  or  enters  a  waiting  state. 

This  algorithm  provides  a  consistent  concurrency  ocr- 
trol  for  which  every  transaction  terminates.  Cor. si  .ter  cy 
is  maintained  because  a  tr  ar.  sac  ti  or  holds  all  locks  until 
it  has  completed.  Thus,  two-phased  looking  ; 5  insured. 
To  see  that  every  transactior  terminates,  rote  that  at  arv 
giver.  time,  due  to  the  uniqueness  of  the  timestamp,  there 
is  exactly  ore  "oldest"  transactior..  That  trar  sootier  oar 
never  be  wounded  ar.d  thus  must  terminate.  At  that  point, 
there  is  a  new  "oldest"  trar.sactior  which  els:  must  ter¬ 
minate.  A  transactior  retains  its  original  t  i  -or  t  ever 
if  it  is  restarted. 

3.3.2.  Simulation  Imolemer  taticr 

To  apply  the  above  algorithm  to  the  distri:  ute  1  »r -ar  - 
sac  tier  processing  discussed  in  this  <  harder-,  it  -  J;-,. 
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first  be  noted  that  a  wounded  transactior  can  be  active  at 
more  than  ore  site.  Thus,  the  decision  to  abort  and  res¬ 
tart  a  transaction  might  be  initiated  at  several  sites.  A 
wound  or  kill  message  for  an  already  killed  tr ar: sactior  is 
simply  ignored.  When  a  transaction  is  restarted  a  'cycle 
number'  is  incremented.  The  cycle  number,  initially  zero, 
is  included  ir.  the  message  addresses  so  that  the  restarted 
transactior  does  not  erroneously  receive  an  old  wound  or 
kill  message. 

A  second  simple  modification  to  the  [ROSE77]  algo¬ 
rithm  was  also  made.  A  transactior  receiving  a  wound  mes¬ 
sage  is  rot  restarted  unless  that  transactior  is  blocked 
by  or  becomes  blocked  by  a  transactior.  that  the  original 
transactior:  cannot  wound  .  In  other  words,  a  wounded  tran¬ 
sactior.  must  be  restarted  if  and  only  if  it  is  blocked  by 
ar:  older  trar:  sactior: .  Note  that  this  algorithm  still 
resolves  any  potential  deadlock  and  all  transactions  must 
eventually  terminate. 

Theorem:  This  modified  wound-wait  system  still  preserves 

persistency  and  every  ore cess  terminates. 

Proof:  The  database  cor  sister cy  is  preserved  since  the 

lockir  s  is  still  two -phased. 

Every  process  will  term!:  ate,  since  a  deadlock  cycle 
carnet  exist  ir  the  wait- for  graph.  The  wait-for  graph  is 


a  directed  granh  where  the  r  :des  r e :w <-•  r.er  t  tr  a:  r>i;  ‘  i  r  s  lr 
the  system.  An  arc  from  ere  node  to  another  imp'.  i  er  that 
the  f’rst  rode  reoreser.  ts  a  transact]  or  that  is  bio.  k<- i  by 
the  trarsactior  represented  hy  the  sec  or d  rode. 

Suppose  a  deadlock  cycle  existed  in  the  rrraph  betweer 
nodes  T^,...,Tr  (i.e.,  is  blocked  by  T^  ,  is  blocked 
by  is  blocked  by  ,  and  is  blocked  by 

T.j  ).  Without  loss  of  e’er  er  a  1  i  t  y  ,  assume  is  the  oldest 
transaction.  Then  must  wound  T^. 

If  T  2  can.  wound  ,  it  does.  If  not,  T?  is  aborted  and 
the  deadlock  no  lor.e,er  exists. 

Similarly,  if  any  cannot  wound  Ti  +  1  ,  it  must  be 

aborted  . 

If  all  of  the  ( i  =  2 , . . . , r )  are  wour  ded ,  so  is  T  . 

But  Tr  is  blocked  by  and  cannot  wcur:d  T .  because  of  our 

assumptions. 

Thus,  T  must  be  aborted  an  i  restarted  an  d  the  iea  : '  c>c 
cycle  is  broker. 

i  _  r  .  r  . 

To  implement  the  at ;  .•  e  air*  or  i  i  h~  5  >,• « r  al  •-  -  *  ■  ••  .  v  -  _ 

tiors  to  the  simulator  were  hirst,  t  .c  -  i 

time  of  each  tr=r  sactirr  w  •»  s  •-  ear  *  t  •  •«  :  ev 

ir.sur  ir  q  that  all  tr  an  sac  1 1  s  arrive  :  v  1  or  e  ♦  1 


unit  apart.  Thfe  arrival  time,  concaten ated  with  a  node 
number,  in  the  least  significant  bits,  is  the  unique 
timestamp  associated  with  the  transaction.  In  addition,  a 
cycle  number  is  added  to  each  transaction  in  order  to 
insure  that  a  restarted  transaction  is  riot  wounded  or 
killed  by  a  message  intended  for  an  earlier  incarnation. 
When  a  transaction  (SLAVES  excepted)  is  first  placed  on 
the  pending  queue,  the  cycle  number  is  initialized  to 
zero.  Messages  are  only  delivered  to  transactions  with 
the  correct  cycle  numbers.  Messages  destined  for  earlier 
cycles  are  simply  discarded.  A  SLAVE  transaction  takes  on 
the  timestamp  and  cycle  number  of  its  corresponding  MAS¬ 
TER.  The  following  steps  are  now  followed  by  a  transac¬ 
tion.  . 

1)  A  transaction  leaves  the  pending  queue.  If  the  tran¬ 
saction  is  a  MASTER  and  this  is  the  first  time  this 
incarnation  has  left  the  pending  queue,  "SLAVE 
create"  messages  are  sent  to  the  appropriate  nodes. 

2)  After  leavirg  the  pending  queue,  a  tr  an  sac  ti  or. 

requests  the  locks  reeded  at  that  site.  If  the  locks 
are  granted  the  trnrsaetiot  proceeds  to  the  I/O,  CPU 
and  data  trarsmissicr  queues.  If  the  leeks  are 
denied,  the  trarsacticr  is  placed  on  the  blocked 
queue  for  this  node.  Let  Tl  be  the  requestirg  trar- 


saction  and  T2  be  the  blocking  tr  an  sac- 1 1  or 
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respec¬ 
tively.  If  both  T1  and  T2  are  distributed  transac¬ 
tions  (SLAVES  or  MASTERS)  and  T1  is  older  than  T2, 
transaction  T2  is  "wounded".  If  T1  is  younger  than 
T2  and  has  been  previously  wounded,  T1  is  killed. 

3)  Once  the  locks  are  granted,  the  transactior s  proceed 
on  the  I/O,  CPU  and  data  tr  an  smi  ssior-  queues  ns 

before . 

4)  A  SLAVE  transaction  sends  a  "SLAVE  complete"  message 
to  its  MASTER  and  waits  or  the  Network  dor e  queue  for 
a  release  locks  message.  A  MASTER  transactior  waits 
on  the  Network  done  queue  until  all  of  its  SLAVES 
have  compl eted . 

5)  When  all  of  the  SLAVEs  have  completed,  the  '-’ASTER 
sends  a  "release  locks”  message  to  all  of  its  SLAVEs, 
releases  its  locks,  and  becomes  a  rew  transact) or  or 
the  pending  queue.  At  this  point  the  trar  sac  tier  is 
considered  dore.  When  a  SLAVE  rec  eives  t  >,•->  "release 
locks"  message,  it  releases  i‘s  locks  ar  :  !  *->  a  v  s  the 
system . 

6)  When  ary  transaction  releases  its  1'cks,  the 

correspor  d  in  g  blocked  transactions  (if  ary)  are 
placed  at  the  front  of  the  oerding  queue. 
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When  a  transaction  is  wounded,  "wound"  messages  are 
sent  to  the  MASTER  and  all  SLAVES.  When  a  transaction 
receives  a  wound,  it  is  flagged  as  wounded.  If  the  tran¬ 
saction  is  already  blocked  by  a  distributed  transaction 
with  an  older  timestamp,  the  wounded  transaction  is 
immediately  "killed". 

When  a  transaction  is  killed,  "kill"  messages  are 
sent  to  the  MASTER  and  all  SLAVES.  Both  types  of  transac¬ 
tions  release  their  locks  and  blocked  transactions  are 
placed  on  the  front  of  the  pending  queue  as  in  step  6 
above.  Any  time  spent  or:  the  I/O  or  CPU  queues  is  counted 
in  a  "lost  time"  total.  At  this  point  SLAVE  transactions 
leave  the  system.  A  MASTER  transaction  increments  its 
cycle  number  and  is  placed  on  the  back  of  the  pending 
queue  for  a  reincarnation . 

A  few  observ ation s  should  be  made.  First,  in  step  2, 
only  if  both  transactions  are  non-local,  does  a  potential 
wound  have  to  take  place.  If  the  blocking  transactior  is 
local,  it  is  guaranteed  to  firish  since  it  has  preclaimed 
all  of  its  locks.  If  the  blocked  transactior  is  local,  it 
car:  hold  r.o  locks  at  ether  sites  ar.1  thus  ro  lead  lock  can 


occur. 


Second,  when  a  transaction  is  restarted,  it  is  placed 
on  the  pending  queue  behird  any  trarsacticrs  that  it 


blocked.  In  particular,  it  is  placed  behird  the 


transactior  that  caused  the  original  wound.  Thus,  the 
same  wound  will  not  occur  again. 

Note  that  the  extra  "release  lock"  messages  to  the 
SLAVES  are  not  present  in  the  primary  cor. currency  control 
models.  They  are  not  needed  in  those  models  because  all 
locks  are  held  (and  thus  released)  at  the  primary  site. 

3.3.3.  Additional  Parameters 

Four  additional  output  parameters  were  recorded  in 
the  simulation  model  for  the  "wound-wait"  corcurr er c y  con¬ 
trol.  In  addition,  new  types  of  messages  are  classified 

as  lock  messages. 

The  four  output  parameters  are  for  the  number  of 
transactions  wounded  (NTRWOUND)  ,  the  number  of  transac¬ 
tions  killed  (NTRKILL),  and  the  lost  time  attributed  to 
killed  transactions  (DLOSTIO  and  DLOSTCPU).  The  court  of 
the  number  of  tran  sactions  wounded,  NTRVQUND ,  is  made  only 
when  a  cycle  of  a  given  MASTER  receives  its  firs*,  wound. 
Thus,  even  though  the  SLAVES  all  receive  wound  messages, 
the  wounding  of  a  distributed  trar  sac  tier  ir  crlv  irtei 
once. 

Similarly,  the  ccurt  of  the  number  of  t  r  a  n  s  .  1 :  :  t  r 

killed,  NTRKILL,  is  made  only  wher  a  M  A  S  7  E  0  receives  its 

first  ki  11  . 
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The  DLOSTIO  and  DLOSTCPU  parameters  record  the  number 
of  time  units  of  I/O  and  CPU  service  respectively  that. a 
killed  transaction  has  received.  How  much  time  is  actu¬ 
ally  lost  depends  on  both  the  queue  the  transaction  is  or. 
and  the  processing  completed  at  that  queue.  Note  that  the 
definition  of  the  total  I/O  utilization,  TIO  and  the  total 
CPU  utilization,  TCPU  also  changes: 

TIO  =  USEFULIO  +  MESIO  +  LOCKIO  +  DLOSTIO 

TCPU  =  USEFULC  PU  +  MESCPU  +  LOCKCPU  +  DLOSTCPU. 

In  the  "wound-wait"  concurrency  control  algorithm  for 
a  decentralized  database,  "WOUND",  "KILL”  ,  and  ’’lock 
release"  messages  are  all  counted  as  lock  related  mes¬ 
sages.  The  lock  related  messages  used  in  the  primary  site 
models  are  no  longer  relevant. 

3.M.  SNOOP  Model 

A  second  decentralized  concurrency  control  algorithm 
uses  a  'SNOOP'  [STO','78]  or  a  global  deadlock  detector 
[GRAY73]  was  also  simulated.  One  problem  with  the 
" woun d- wa i t "  algorithm  is  that  transactions  may  be  killed 
and  restarted  needlessly.  While  the  algorithm  is  suffi¬ 
cient  to  prevent  deadlock,  it  may  be  too  conservative. 
Transactior.  1  could  be  blocked  by  the  younger  Trarsactior 


■  mi  r  1  i. 
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Transaction'  2  could  be  blocked  by  the  older  Transac¬ 
tion  3 ,  which  can  in  fact  complete.  Even  though  r.o 
deadlock  is  present,  Transaction  2  would  still  be  res¬ 
tarted  . 

In  this  section,  an  algorithm  is  described  which  res¬ 
tarts  transactions  only  when  an.  actual  deadlock  occurs. 
In  section.  3-^.2,  the  implementation  of  that  algorithm  in 
the  simulation  model  is  presented.  In  section  3.^.3 
changes  in  the  simulation,  parameters  are  discussed. 

3  •  ^ .  3.  •  SNOOP  Algorithm 

In  [STON78]  a  decentralized  algorithm  for  concurrency 
control  is  presented.  Each  node  or  site  in  the  distri¬ 
buted  database  is  responsible  for  local  corcurrercy  cor - 
trol  for  the  portion  of  the  database  at  that  site.  If  two 
transactions  conflict,  the  local  concurrency  cor trol  sends 
a  message  about  this  conflict  to  a  designated  site  called 
’  The  SNOOP’. 

— ---Jb 

The  SNOOP  then  detects  deadlock  by  ar  arc  I  vs  is  of  the 
"wait-fon”  graoh  generated  by  ail  su».h  mossa-*°s.  If  a 
deadlock  cor.ditior  is  detected,  a  victim  is  ricKed  to  be 
killed  and  restarted  (a  reir c  arr ati :r  '  .  Note  that  when  j 
transaction  has  completed,  the  S*.'0"P  must  also  be  notified 
so  that  the  appropriate  entries  ir  the  "wait-fc,r"  graph 


can  be  cleared .  ■ 


The  same  basic  idea  was  also  suggested  in  [GRAY78] 
with  several  modifications.  One  modification  is  that  a 
conflict  message  is  only  sent  to  the  SNOOP  if  the  blocking 
transaction  is  directly  waiting  on  a  response  from  another 
node  or  is  blocked  (directly  or  indirectly)  by  some  other 
transaction  that  is  waiting  on  a  response  from  another 
node . 

Another  suggested  modification  is  to  only  send  such 
conflict  messages  and  check  for  deadlock  periodically.  In 
this  manner  the  system  overhead  for  both  handling  lock 
messages  arid  checking  for  deadlock  can  be  reduced  at  the 
cost  of  delaying  the  detection  of  an  existing  deadlock. 

3.«  .2.  Simulation  Implementation 

The  'SNOOP'  simulation  model  is  very  similar  to  the 
wound-wait  model.  The  following  steps  are  taken  in  the 
'SNOOP'  model. 

1)  Same  as  "wound-wait"  model 

2)  Same  as  "wound-wait"  if  the  locks  are  granted.  Sup¬ 
pose  the  locks  are  denied  and  T1  is  the  requesting 
transaction  and  T2  is  the  blocking  transaction.  If 
both  T1  and  T2  are  distributed  transactions  (SLAVES 


or  MASTERS),  a  corflict  message  is  sent  to  ore  of  the 
sites  designated  as  the  SNOOP. 

3,4)  Same  as  "wound-wait"  model. 

5)  Same  as  "wound-wait"  except  that  when  a  MASTER  tran¬ 
saction  is  done,  a  "clear  snoop"  message  is  sent  to 
the  SNOOP. 

6)  Same  as  "wound-wait"  model. 

The  SNOOP  maintains  a  global  "wait-for"  directed 
graph.  Each  rode  represents  a  blocked  or  blocking  tran¬ 
saction.  An  arc  from  node  1  to  node  2  implies  that  the 
transaction  represented  by  node  1  is  blocked  by  the  tran¬ 
saction  represented  by  node  2.  When  a  corflict  message  is 
received,  a  node  for  each  transaction  (if  ore  doesn't 
already  exist)  is  added  to  the  graph  along  with  the 
appropriate  arc.  At  that  point,  the  graph  is  searched  for 
a  cycle  beginning  at  the  node  for  the  blocked  transaction. 
If  deadlock  is  detected,  the  yourgest  (determined  by  the 
unique  timestamp)  of  the  two  trarsactiors  involved  with 
this  conflict  is  declared  a  victim  ar.d  killed.  The  fact 
that  a  giver,  cycle  of  the  victim  was  killed  is  remembered 
by  th«  SNOOP. 
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The  killin’  of  a  transaction  is  identical  to  the  kil¬ 
ling  of  a  transaction  in  the  wound-wait  algorithm.  The 
SNOOP  sends  a  message  to  the  MASTER  and  its  SLAVES.  Both 
tvoes  of  trap  sac  tier s  release  locks  and  record  lost  time. 
A  MASTER  transaction  is  reincarnated  as  in  the  wound-wait 
model  . 

Note  that  it  is  necessary  that  the  SNOOP  remembers 
both  killed  and  completed  tr an  sacti or  s  for  a  given  period 
of  time.  It  is  possible  that  the  SNOOP  could  be  notified 
of  a  conflict  involving  a  killed,  or  completed  transac¬ 
tion.  In  these  cases,  the  conflict  occurred  before  a  node 
received  the  'kill'  or  'release  locks'  message.  In  the 
case  of  a  killed  tr an sactior ,  a  false  deadlock  could  be 
detected.  In  the  case  of  a  completed  transaction,  an 
extra  rode  would  simply  clutter  the  wait-for  graph.  If  a 
killed  or  completed  transaction  is  involved  in  a  conflict 
message,  the  message  is  simply  ignored  at  the  SNOOP  site. 


The  cycle 

r  umber 

is  needed 

by  the  SNOOP  to 

d  i  s  t  i  r.  - 

g  u i s  h  bet w  e e  r 

"  0  S  ?  .1  v  c  s 

mear  t  for 

different  ir.c arr atior s  of 
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red",  the  k i  1 1 

e  d  rede 
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ir.  the  graph. 

If  a  c 
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ssage  arrives  with 

a  lower 

cycle  r  umber  than  the  oorresr or  lire,  :  ode  in  the  graph  ,  the 
message  is  sin  civ  discarded.  Such  messages  are  obsrlete. 


Also  rote  that  in  the  case  of  d <_> h J  lock,  the  vut!m  i  s 
chosen  from  among  the  two  nodes  irvclved  ir:  this  cot  f lict . 
This  choice  is  guaranteed  to  break  any  deadlocks  sirce  the 
graph  is  assumed  to  be  deadlock  free  before  the  latest  arc 
was  added.  This  victim  may  not  be  the  optimum  victim  for 
backout.  However,  if  a  different  victim  were  chosen,  the 
other  parts  of  the  graph  would  still  have  to  be  searched 
for  other  deadlock  cycles. 

Finally  note  that  all  conflicts  between  r.or.-loeal 
transactions  are  sent  immediately  to  the  SNOOP.  As  previ¬ 
ously  mentioned,  it  is  suggested  that  the  corflict.  mes¬ 
sages  should  rot  be  sent  unless  the  blocking  trar.sacticr 
actually  enters  a  "node  wait"  state.  However,  in  this 
model,  both  MASTER  and  SLAVE  transactiors  will  eventually 
wait  for  messages  from  other  nodes  before  they  release 
their  locks.  Since  that  'node-wait'  state  is  inevitable, 
the  corflict  messages  are  sent  immediately. 

3.^.3.  SNOOP  P  ar ameter s 

As  with  the  ”wour  d-wait"  al a - r i t h"  ,  eevr- ~1  r  ew 
parameters  are  introduced  and  the  defit  it:  or  of  1;.-:  mes¬ 
sages  is  char  ged  . 

The  cost  to  check  for  decs! cck  is  very  ey : er  r  \  ve  ; 
often  this  cost  is  much  rreater  the  c  :  - 1  t:  c-r-t  a 
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simple  lock  [GRAY731.  A  new  network  input  parameter, 
SNOOPRATE,  was  added  to  the  simulation  to  model  that  addi¬ 
tional  cost.  Every  time  a  conflict  message  is  received  by 
the  SNOOP,  SNOOPRATE  time  units  are  added  to  the  locking 
costs  at  the  SNOOP  node.  Note  that  conflicts  involving 
killed  or  completed  transactions  are  not  included.  In 
most  of  the  experiments,  a  SNOOPRATE  of  .5  is  used.  In 
the  canonical  interpretation  this  value  represents  about 
15  milliseconds  or  about  5  times  the  cost  to  set  a  lock. 

The  NTRKILt,  DLOSTIO,  and  DLOSTCPU  parameters  from 
the  wound-wait  model  are  also  included  in  the  SNOOP  simu¬ 
lation.  However,  rather  than  the  NTRWOUND  parameter,  the 
SNOOP  model  records  the  NUMCONFLCT  parameter,  the  number 
of  actual  conflict  messages  received.  Again,  conflict 
messages  for  already  killed  or  completed  transactions  are 
not  included  in  this  count. 

The  lock  messages  in  the  SNOOP  model  are  the  'con¬ 
flict'  messages,  the  'kill'  messages,  the  'release  locks' 
messages  and  the  'clear  SNOOP'  messages. 


4.  RESULTS  AND  .DISCUSSION 

The  results  for  the  distributed  database  si'nu  la  tiers 
are  presented  in  this  sectior  .  In  the  first  seeticr  we 
present  the  results  for  the  parameter  settings  for  the 
canonical  scenarios.  Subsequent  sectiors  review  the 
effects  of  varying  the  number  of  SLAVES  for  each  distri¬ 
buted  transaction  (NSLAVES),  the  number  of  nodes  in  the 
network  (NNODES),  and  the  percent  of  distributed  transac¬ 
tions  ( PREDIST ) . 

In  section  4.5,  the  results  of  varying  the  network 
parameters  are  repeated.  These  parameters  are  the  message 
rate  (MESRATE),  the  network  bandwidth  (MES8DWT),  the  CPU 
rate  for  processing  messages  (MESCPURATE)  and  the  percen¬ 
tage  of  data  transferred  (PRETRAM  and  PREDAT'D.  Finally, 
the  canonical  cases  are  revisited  in  section  4.6  with  a 
different  network  environment. 

The  results  are  reported  for  each  of  the  four  con¬ 
currency  control  algorithms  simulated  and  the  two  dif¬ 
ferent  classes  of  transaction  sizes.  The  first  primary 
site  model,  where  locks  for  one  site  are  held  while  wait¬ 
ing  for  locks  at  another  site,  is  denoted  "PS1".  The 
second  primary  site  model  is  denoted  "PSP"  .  The  notatior 
"WW"  refers  to  the  wound-w; it  algorithm,  while  "SNOOP" 
refers  to  the  algorithm  with  the  single  global  deadlock 


A 


de  tec  tor  . 


Transactions  in  class  1  refer  to  transactions  whose 
sizes  are  generated  by  a  hyper  ex ponential  distribution  and 
well-placed  locks  are  assumed.  Transactions  in  class  2 
refer  to  transactions  whose  sizes  are  mainly  small  (gen¬ 
erated  by  an  exponential  distribution).  In  this  case, 
random  lock  placement  is  assumed. 

In  the  first  three  sections,  an  unlimited  network  is 
assumed  in  order  to  study  the  effects  of  the  different 
concurrency  control  algorithms  on  the  processing  at  each 
of  the  nodes.  Beginning  in  section  4.4,  network  limita¬ 
tions  are  introduced  to  study  the  effects  of  the  con¬ 
currency  control  algorithm  or.  the  network  resources. 

4.1.  The  Car^ani_cal  Scenarios 

The  canonical  scenarios  refer  to  the  cases  where  the 
input  parameters  have  the  settings  shown  in  Table  3-5. 
For  these  experiments,  as  in  Chapter  2  ,  the  number  of 
locks  (MORAN),  was  varied  from  1  up  to  DBSIZE  and  reflects 
the  number  of  locks  at  each  node.  One  lock  implies  that 
at  each  node,  only  ore  transaction  can.  be  active  at  ore 
time.  With  10,000  locks,  there  is  ore  lock  for  each 
entity  at  each  node  and  transactions  can  proceed  if  the 
entities  they  require  are  not  being  accessed  by  any  other 
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transaction  . 


Table  3-6  shows  the  expected  r umber  of  each  type  of 
message  under  the  canonical  parameter  settings.  Each 
non-local  transactior.  sends  5  (MSLAVE)  slave  create  mes¬ 
sages  and  receives  5  slave  completed  messages.  In  addi¬ 
tion,  40%  (PRETRAN)  of  the  non-local  transactions  send  6 
(NSLAVES  +1)  data  transfer  messages.  These  non-local  mes¬ 
sages  are  the  same  for  all  four  concurrency  control  algo¬ 
rithms  . 

However,  the  four  algorithms  send  different  numbers 
of  lock  messages .  In  the  primary  site  models,  transac¬ 
tions  at  5  of  the  6  rodes  (all  nodes  other  than  the  pri¬ 
mary  site)  have  three  lock  messages:  "request  locks", 
"grant  locks",  and  "release  locks".  In  the  decentralized 
models,  only  the  non-local  transactions  send  lock  mes¬ 
sages.  Those  messages  include  the  5  (NSLAVE)  release  lock 
messages  plus  some  messages  for  wounding  transactions, 

Table  3-6 

Expected  Messages  per  Transaction 

PS1-PS2  WoW-SNOOP 


Local 

Non- local 

Loc  al 

Nor  - local 

Non-lock 

Messages 

0 

10+(  .4)6 

0 

10+ ( .4)6 

Lock 

Mesaages 

3(5/6) 

3(5/6) 

0 

5+?  (WW) 
5+ (5/6 )+? 
(SNOOP) 

k i  1 1  i r: transactions  and/or  notifying  the  SNOOP  of  con¬ 
flicts.  In  addition,  in  the  SNOOP  model,  a  non-local 
transaction  at  other  than  the  SNOOP  site  must  send  a 
"clear  SNOOP’"  message  when  it  has  completed. 

The  results  for  the  canonical  scenarios  are  presented 
for  class  1  and  class  2  transactions.  Figures  3-1'  and  3-5 
show  the  effects  of  varying  the  number  of  locks  at  each 
node  on  the  USEFULIO  for  each  of  the  four  concurrency  con¬ 
trol  algorithms.  The  horizontal  axis  represents  the 
number  of  locks  in  a  logarithmic  scale.  The  vertical  axis 
is  the  USEFULIO,  or  I/O  resources  used  in  completing  tran¬ 
sactions,  in  1000  time  units  of  the  simulation.  Note  that 
for  six  nodes,  at  most  120,000  time  units  ( NNODES*TMAX )  of 
1/0  resources  are  available.  The  curves  for  the  USEFULCPU 
measurements  were  very  similar  and  are  not  shown. 


*1.1. 1_«  Class  1  ZL3r- s  s 

Figure  3-f*  shows  the  results  for  class  1  transac¬ 
tions.  For  all  four  concurrency  control  algorithms,  the 
maximum  USEFULIO  occurred  with  500  to  1000  granules.  For 
the  primary  site  2  (PS2)  and  the  global  deadlock  detector 
(SNOOP)  models,  the  peak  occurred  at  500  granules.  For 
the  primary  site  1  (PS1)  and  wound-wait  (WW)  models,  1,000 
granules  were  optimal.  In  either  case,  with  1%  of  the 


maximum  USKFULIO  was  reached  with  500  or  1000  granules. 

Several  observation  about  figure  3-*i  should  be 
noted.  First,  the  primary  site  two  model  (PS2)  achieved 
98%  of  the  maximum  USEFULIO  with  100  granules  and  90%  of 
that  maximum  with  as  few  as  50  granules.  Each  of  the 
other  three  models  required  at  least  250  granules  to  reach 
within  10  percent  of  its  respective  maximum.  Thus,  more 
coarse  granularity  was  acceptable  in  the  primary  site  two 
model.  In  that  model,  no  transactions  held  locks  at  one 
node  while  waiting  for  locks  at  another  node.  In  each  of 
the  other  models  this  condition  was  not  true. 

Second,  the  differences  in  useful  computer  utiliza¬ 
tions  were  very  small  at  the  optimum  granularities, 
although  the  primary  site  two  model  (PS2)  did  show  a 
slight  advantage.  At  lower  granularities,  the  primary 
site  models  produced  significantly  more  useful  computer 
utilization  since  transactions  did  not  have  to  be  res¬ 
tarted.  Similarly,  at  lower  granularities,  the  SNOOP 
model  out- per  formed  the  wound-wait  model,  since  it  caused 
even,  fewer  transactions  to  be  restarted. 

The  average  response  time  curves  (rot  shown)  for  the 
transactions  in  class  1,  did  not  consistently  favor  any  of 
the  four  algorithms.  However,  at  or  near  the  optimum 
granularity  (1000  leeks  at  each  node),  the  decentralized 
algorithms  had  a  better  average  response  time  than  the 
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primary  site  1  model.  This  result  is  expect'-.;!,  siuo 
local  transactions  car:  be  run  without  network  delay. 

Surprisingly,  however  ,  the  average  reaper  se  time  was 
even  less  for  the  primary  site  2  model.  In  this  case,  ary 
gains  observed  by  the  local  transactions  in  the  decentral¬ 
ized  models  were  more  than  offset  by  the  extra  delay 
experienced  and  caused  by  distributed  transactions  holding 
locks  at  one  node  while  waiting  for  locks  at  anoth  -r  r  ode! 

The  exact  values  of  the  output  parameters  observed 
with  500  locks  at  each  node  for  class  1  transactions  are 
reported  in  Table  3-7. 


Several  observations  should  be  noted.  At  the  primary 
site  2  model,  the  number  of  transactions  completed,  TRAM- 


Table  3-7 

Output  Measurements  for  Class  1  Type  Transactions 


Measuremer  t 

PS  1 

PS2 

ww 

SNOOP 

TRANCOM 

2,688 

3,307 

3,094 

3,029 

AVERRES 

392 

350 

368 

362 

USEFUL  10 

86,056 

87,6*18 

87,518 

87,556 

USEFULCPU 

86,065 

86,335 

87 , 522 

87,563 

LOCKCPU 

8*1 3 

1  ,048 

952 

962 

MESSCPU 

207 

265 

108 

1  03 

TMESS 

9,697 

12,437 

5,408 

5,178 

LMESS 

6,799 

8,329 

1  ,545 

1  ,664 

NWOUNDED 

6 

NCONFLICTS 

_ 

— 

_ 

68 

NRESTARTED 

— 

— 

1 

0 

DL0STI0 

- 

- 

392 

0.0 

DLOSTCPU 

- 

- 

392 

0.0 

COM,  was  10%  greater  than  with  the  two  distributed  control 
models  and  about  18%  greater  than  with  the  primary  site  1 
model.  However,  the  differences  in  USEFULIO  and  USEFULCPU 
were  not  significantly  different  for  the  four  concurrency 
control  models.  Thus,  the  large  TRANCOM  value  was  due 
primarily  to  the  fact  that  the  PS2  model  favored  smaller 
transactions  and  90%  of  the  workload  included  those  small 
tr an  saction  s  . 

With  the  other  models,  larger  distributed  transac¬ 
tions  could  block  both  large  and  small  transactions  at 
several  nodes  while  waiting  for  locks  at  another  node. 
With  the  PS?  model,  however,  the  larger  distributed  tran¬ 
sactions  (which  have  the  greatest  probability  of  con¬ 
flict),  would  release  the  locks  at  lower  numbered  nodes. 

The  LOCKCPU ,  MF.SSCPU,  TMESS  and  LMESS  parameters  were 
also  greater  for  the  primary  site  ?.  model,  since  more 
transactions  had  been  completed. 

As  expected,  message  CPU  overhead  was  lowest  for  the 
decentralized  concurrency  control  algorithms.  Also  note 
that  the  ratio  of  the  total  number  of  lock  messages  sent 
to  the  total  number  of  messages  sent  ( LMESS/TMESS )  is 
about  for  the  orimary  site  models  versus  .3  for  the  decen¬ 
tralized  control  models.  In  other  words,  two-thirds  of 
the  network  traffic  was  due  to  concurrency  control  in  the 
primary  site  models.  Less  than  one-third  of  the  messages 
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in  the  decentralized  models  were  for  concurrency  control. 

The  expected  number  of  messages  shown  in  Table  3-6 
can  be  applied  to  the  number  of  observed  messages  shown  in 
Table  3-7  to  determine  the  exact  number  of  lock  messages 
sent  by  local  transactions.  In  the  primary  site  2  model, 
for  example,  4,108  non-lock  messages  (TMESS-LME5S )  had 
been  sent.  Since  the  expected  number  of  non-lock  messages 
is  12.4,  311  of  the  3,307  transactions  were  nor-local. 
(Note  that  this  number  is  consistent  with  3,307  total 
transactions  and  a  PREDIST  value  of  10%. )  Thus  2,996  tran¬ 
sactions  were  entirely  local  and  yet  were  resporsible  for 
7,490  lock  messages. 

Notice  that  a  very  small  number  of  transactions  were 
wounded.  In  the  canonical  scenario  only  10%  of  the  tran¬ 
sactions  were  distrbuted  and  orly  conflicts  between  dis¬ 
tributed  transactions  could  cause  wounds.  Furthermore, 
all  locks  are  requested  at  the  beginning  of  a  transaction 
and  were  generally  granted.  Thus,  a  transaction  is  much 
more  likely  to  be  blocked  by  an  older  transaction,  in 
which  case  no  wound  is  sent.  Note  that  many  more  con¬ 
flicts  than  wounds  were  sent.  However,  r-.o  deadlock  was 
detected,  so  no  transactions  were  restarted  in  the  SNOOP 


model . 


The  number  -of  conflicts  in  the  L'NOOP  model  was  always 
greater  or  equal  to  the  number  of  transactions  wounded  in 
the  wound-wait  model,  since  all  conflicts  between  distri¬ 
buted  transactions  were  sent  to  the  SNOOP.  However,  the 
number  of  killed  or  restarted  transactions  in  the  SNOOP 
model  was  always  less  than  or  equal  to  the  number  res¬ 
tarted  in  the  wound-wait  model,  since  only  actual 
deadlocks  could  cause  a  restart.  In  fact,  in  the  simula¬ 
tion  results  reported  in  Table  3-7,  no  transactions  were 
restarted  in  the  SNOOP  model. 

1*1* Class  2  Transactions 

The  USEFUL  10  computer  utilization  for  each  of  the 
four  concurrency  control  algorithms  for  class  2  transac¬ 
tions  are  shown  in  Figure  3-5.  Under  the  randomly  placed 
locks  with  only  small  transactions,  the  finest  granular¬ 
ity,  10,000  locks  in  this  case,  was  again  optimal.  With 
this  optimal  granularity,  as  with  class  1  transactions, 
only  slight  differences  in  computer  utilizations  were  due 
to  the  concurrency  control  algorithms. 

However,  the  wound-wait  and  global  deadlock  detector 
algorithms  did  cor1  si  sten  tl  y  produce  somewhat  better 
results  than  the  primary  site  algorithms  over  a  wide 
variety  of  granularities.  In  fact,  only  with  fewer  than 
50  locks  at  each  rode,  were  the  primary  site  models 


SNOOP 
PS  I ,  PS2 


No.  of  locks  (log  scale) 

Figure  3-5:  Productive  computer  utilization  with 
four  algor i Hints  and  Class  2  Transact 


ions . 
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advantageous , 

No  difference  in  computer  utilisation  was  observed 
between  the  two  primary  site  models  once  the  granularity 
became  fine  enough.  This  result  was  true  for  class  2 
transactions,  since  the  probability  of  success  or  a  lock 
request  was  extremely  high.  Thus,  very  few  of  these  tran¬ 
sactions  waited  for  locks  at  one  node,  while  holding  locks 
at  another  node. 

Similarly,  once  the  granularity  was  less  coarse 
(about  50  granules),  little  difference  in  computer  utili¬ 
zation  is  realized  between  the  two  decentralized  algo¬ 
rithms.  This  result  was  also  realized  because  of  the  high 
probability  of  success  or.  a  lock  request. 

Figure  3-6  shows  the  average  response  time  versus  the 
number  of  locks  at  each  node  for  class  2  transactions. 
The  response  time  is  given  in  terms  of  time  units  of  the 
simulation.  In  the  canonical  interpretation  of  the  time 
parameter,  a  resnonse  time  of  61  would  represent  about  1.8 
seconds.  The  dichotomy  between  the  primary  site  algo¬ 
rithms  and  decentr al i zed  algorithms  was  again  realized  in 
these  curves.  As  expected,  the  decen tr al  i  zed  algorithms 
produced  lower  average  response  times,  since  local  tran¬ 
sactions  did  not.  need  to  communicate  with  any  other  nodes. 

The  exact  values  of  the  output  measurements  for 
10,000  locks  at  each  node  are  reported  in  Table  3-8  for 


Average  response  time  (time  units  of  simulation) 


IS] 


No.  of  locks  (  log  scale  ) 

Figure  3-6:  Average  Response  time  for  four 

algorithms  and  Class  3  Transactions. 
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class  2  transaction s . 


Note  that  the  network  parameters  observed  the  same 
ratios  of  total  messages  to  lock  messages  as  with  the 
class  1  transactions.  However,  the  differences  in  the 
number  of  lock  messages  between  the  primary  site  models 
and  the  decentralized  models  was  over  40, 000  messages  with 
class  2  tr an  sac t i or s  .  With  that  number  of  messages  it  is 
no  longer  realistic  to  assume  that  the  network  is  'lightly 
loaded'  i.e.,  that  the  message  bandwidth  parameter  is 
infinite.  Restricting  the  message  bandwidth  can  only 
increase  the  differences  between  the  primary  site  control 
and  decentral  ized  control  models  as  will  be  shown  in  sec¬ 
tion  4.5. 


Table  3-8 

Output  Measurements  for  Class  2  Type  Transactions 


Measurement 

PS1_ 

PS2 

WW 

SNOOP 

TRANCOM 

18,455 

18,461 

19,259 

19,097 

AVER  RES 

64 

64 

61 

62 

USEFUL  10 

93,956 

93,280 

97,135 

96,193 

USEFIILCPU 

93,996 

93,319 

97 , 145 

92,204 

MESSCPU 

1,519 

1 ,529 

670 

700 

TMESS 

73,977 

74 , Pd? 

73,520 

34,852 

LMFSS 

51 ,594 

51 ,234 

9,635 

11,093 

NW0UMDED 

NCONFLI CTS 

0 

- 

- 

5 

N RESTAR TED 

- 

- 

0 

0 

DL0STI0 

- 

— 

0 

0 

DL0STCPU 

- 

- 

0 

0 
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The  relatively  small  d  i  f  f  erer  u  es  i:  nvora-v  res  per  re 
times  between  the  primary  site  ar.d  decor.  tral  i  reel  control 
models,  was  at  first  surprising.  However,  most  of  the 
delay  for  the  trarssactior  s  was  due  to  compet  i  t.  i  r  r  for  the 
CPU  and  I/O  resources.  The  network  delay  time  of  2  *  ME5- 
RATE  time  units  was  not  a  relevant  factor.  For  example, 
with  ten  transactions  at  each  node,  a  local  transactior 
was  active  at  a  site  with  9  other  transactions .  For  class 
2  transactions,  the  average  tran S3ction  size  was  5.  Thus 
a  transaction  waited  for  the  I/O  and  CPU  resources  for 
about  45  time  units  (9  trars  X  5  time  un  i  t.  s/ tr  nr.  s )  .  In. 
addition,  the  average  transactior  would  spend  5  time  units 
using  the  I/O  and  CPU  resources. 

Thus  55  time  units  of  the  average  resporse  time  is 
accounted  for  without  considering  lock  conflicts  or  r et- 
work  delays.  If  either  fewer  transactions  were  running, 
the  transactior;  sizes  were  smaller,  or  the  network  were 
slower,  the  2  *  MESRATE  delay  would  further  increase  the 
response  time  difference  between  the  primary  site  and 
decentralized  models. 

The  expected  number  of  messages  shown  in  Table  3-6 
can  also  be  used  in  analyzing  the  number  of  messages  shown 
in  Table  3-8.  In  this  case,  1,859  transactions  were  non- 
local  in  the  primary  site  2  model.  Thus,  the  16,502  local 
transactions  accounted  for  4 1 , 505  of  the  lock  mess' ges. 
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Note,  however,  that  the  number  of  lock  messages  in 
both  primary  site  models  is  higher  than  the  expected 
number  of  messages  according,  to  Table  3-6.  For  18, 461 
transactions  completed,  46,153  (TRANCOM  *  3(5/6))  lock 
messages  should  have  been  sent.  This  difference  was  due 
to  a  slight  bottleneck  at  the  primary  site.  In  computing 
the  expected  value  it  was  assumed  that  5  out  of  every  6 
transactions  comnleted  would  be  initiated  at  other  sites 
and  thus  require  the  lock  messages.  However,  due  to  the 
bottleneck  at  the  primary  site,  9  out  of  every  10  transac¬ 
tions  were  initiated  at  other  sites. 

In  the  next  sections,  the  effects  of  variation  in  the 
input  parameters  on  the  above  observations  are  reported. 

4.2.  §lj3ve  Transactions 

In  a  distributed  database,  not  all  of  the  distributed 
transactions  require  access  to  data  at  all  of  the  nodes  as 
assumed  in  the  above  results.  In  this  set  of  experiments, 
the  number  of  SLAVES  required  by  each  MASTER  transaction, 
NSLAVE,  was  set  to  1 ,  3  and  5.  With  these  settings  of 
NSLAVES,  a  distributed  transaction  thus  accessed  data  at 
2,  4  and  6  rodes,  respectively.  The  results  of  these 
parameter  settings  for  class  1  and  class  2  type  transac¬ 
tions  for  the  four  concurrency  algorithms  follow. 


.  ?.1_-  C^ass  1  'Trnrsfu  tiors 

The  affects  of  varying  the  number  of  SLAVES  wei'o 
similar  under  any  of  the  four  corcurrency  control  algo¬ 
rithms.  The  maximum  useful  computer-  utilization  again 
occurred  with  500  or  1000  granules  regardless  of  the 
number  of  SLAVES  used  by  a  distributed  transaction  .  In. 
addition,  all  four  concurrency  control  algorithms  resulted 
in  similar  shifts  in  the  utilization  curves  as  the  number 
of  nodes  per  distributed  transaction  varied.  The  shifts 
are  shown  for  the  SNOOP  algorithm  in  Figure  1-7. 

As  expected,  as  the  number  of  SLAVES  decreased,  the 
useful  computer  utilization  increased.  Although  the 
optimal  granularity  did  not  change,  the  number  of  granules 
required  to  achieve  utilization  close  to  the  maximum 
decreased  as  the  number  of  SLAVES  decreased.  If'  each  MAS¬ 
TER  transaction  had  1  SLAVE,  50  locks  resulted  in  95%  of 
the  computer  utilization  realized  with  500  locks.  With  3 
SLAVES,  91  %  of  the  maximum  utilization  was  realized  with 
50  locks,  while  only  63%  was  realized  if  there  were  5 
SLAVES  for  each  MASTER  trars  action.  Thus,  as  the  number 
of  remote  nodes  decreased,  the  acceptable  granularity 
results  resembled  those  observed  in  Chapter  ?  for  the  cen¬ 
tralized  database. 


UsefulIO  (  x  k  time  units  } 


As  previously  stater!,  the  other  three  do  i  <; 
similarly.  In  general,  varying  the  Mentor  of  SLAV!/:  for- 
distributed  transactions  did  rdt  have  a  large  i.npn  i  r 
the  processing  at  the  nodes.  However,  tl  <-  ut  1 1  i  rat  )  a  o< 
the  network  as  a  function  of  the  ram  her  of  rorn->  to  r  >-dos 
does  depend  on  the  concurrency  control  algor  i  thm  used . 
Table  3-9  shows  the  percentage  of  "useful"  messages  (r  .r- 
lock  related)  for  each  of  the  four  algorithms.  V :  ’  n  '  ho 
primary  site  models,  the  number  of  lock  me:;-. are,-.  "t.avod 
constant,  but  the  number  of  nor  - lock  messages  O'-we;  .1  .  > 
the  number  of  SLAVES  for  each  MASTER  tramoti  or  .  Vith 
the  decer-tral  ized  algorithms,  of  course,  the  r  ir.'^-r  ■!’ 
lock  messages  decreased  as  the  number  of  slaves  dec  rea.-,.-  :  . 

jt.2.2.  Class  2  Tran. sac t i or- s 

The  number  of  SLAVES  for  a  distributed  transact lot 
also  had  little  effect  or-  the  choice  of  cor  currer  c v  cot - 
trol  algorithm  or  grarul  arity  for  class  ?  trnrsvii  r  . 
As  in  the  canonical  scenario,  the  finest  gram!  u  i‘v  wia 
again  optimal.  In  the  primary  site  models,  tue  r  <  r  <-v 
Table  3-9  Useful  Network  Traffic 


( Nor  - loc  k 

Me  s sages ) 

of  SLAVES 

PS1 

PS? 

WW 

SNOOP 

9% 

1  1% 

71% 

6h% 

21% 

21% 

71% 

6f»% 

30% 

33% 

711 

6  H% 

1 

3 

5 
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utilization  and  average  response  time  as  a  function  of  the 
number  of  locks  were  almost  identical  for  one,  three  and 
five  SLAVES  for  each  MASTER  transaction.  For  the  decen¬ 
tralized  concurrency  control  models,  those  three  curves 
were  nearly  identical  with  more  than  50  granules.  With 
fewer  granules,  more  SLAVES  resulted  in  more  transactions 
being  restarted.  In  these  cases,  the  computer  utilization 
was  decreased.  However,  even  with  only  one  slave  Der  dis¬ 
tributed  transaction,  performance  of  the  system  with  class 
2  transactions  was  still  extremely  bad  with  coarse  granu¬ 
larity  . 

The  observations  on  the  network  utilization  for  class 
1  transactions  also  hold  for  transactions  in  class  2.  In 
fact,  while  the  number  of  total  and  lock  messages  changed, 
the  percentages  of  useful  messages  were  approximately  the 
same . 

U.3.  Number  of  Network  Nodes 

The  number  of  sites  in  a  distributed  database  can 
vary.  The  simulation  models  were  run  with  2,  4,  6  and  8 
sites  for  a  variety  of  granularities.  In  order  to  keep 
the  other  factors  constant,  the  canonical  scenarios  were 
changed.  In  all  of  these  experiments,  it  was  assumed  that 
each  distributed  tran sactior.  required  only  ore  slave  run¬ 
ning  at  another  site. 


4.3.1,.  Class  1 'Transact  i  or  s 

With  mixed  transaction  sizes  and  well-nlrued  locks, 
there  was  practically  no  difference  between  the  four  c o t - 
currency  control  algorithms  as  the  number  of  nodes  ir  the 
network  varied.  Moreover,  neither  the  optimum  granulari¬ 
ties  nor  the  shapes  of  the  useful  utilizatior  versus 
granularity  curves  changed  as  the  number  of  nodes  in.  the 
network  varied.  The  curves  all  resembled  those  shown  in 
figure  3-4. 

The  only  changes  in  the  computer  utilizations  were  ir. 
magnitude,  and  those  changes  were  linear  with  respect  to 
the  number  of  nodes.  Note,  however,  that  it  is  also 
assumed  that  the  network  resources  also  increase  as  the 
number  of  nodes  increase.  Under  the  wound-wait  simula¬ 
tion,  for  example,  with  2  nodes  the  maximum  useful  utili¬ 
zation  was  30,119  time  units;  with  4  nodes,  ‘39,705  time 
units,  with  6  nodes,  90,472  time  units,  while  with  8 
nodes,  120,327  time  units  were  used  ir.  process  i  r  g  transac¬ 
tions. 

The  average  resporse  time,  on  the  other  hard,  lid  nc-t. 
vary  as  the  number  of  nodes  changed. 
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4.3.2.  Cl^ass  2  Transactions 

Linearity  in  computer  utilization  as  a  function  of 
the  number  of  nodes  was  also  observed  for  class  2  type 
transactions.  The  USEFULIO's,  USEFULCPU's  and  average 
response  time  for  the  decentralized  concurrency  control 
algorithms  were  slightly  better  than  those  measurements 
for  the  primary  site  with  2,  4 ,  6  or  8  nodes  in  the  com¬ 
puter  network. 

The  cost  of  locking;  with  the  many  small  transactions 
and  the  random  placement  of  locks  assumption,  is,  of 
course,  much  greater  than  with  the  class  1  transactions. 
This  cost  also  increased  linearly  with  the  number  of  nodes 
and  was  practically  the  same  for  all  four  algorithms  at 
the  optimum  granularity.  The  lock  costs  for  the  primary 
site  1  model  are  shown  in  Table  3-10: 

The  time  units  per  node  remained  relatively  constant. 
However,  for  the  decentralized  concurrency  control  algo¬ 
rithms,  the  time  units  used  for  locking  were  distributed 
among  all  of  the  nodes.  In  the  primary  site  models  all  of 

Table  3-10:  Time  Units  Spent  Locking 


No.  of  Nodes 

Total  Time  Units 

Time  Ur  its  Der  Node 

2 

360  8 

" .  17’0'i 

4 

676  3 

1691 

6 

10010 

1673 

8 

13300 

1663 

the  time  units  were  used  for  locking  at  ore  node.  Thus, 
at  the  primary  site  with  S  nodes  in  the  network,  13, 80° 
out  of  20,000  available  time  units  were  used  for  locking. 

This  increasing  overhead  for  locking  at  ore  node  has 
two  implications .  First,  transactions  which  use  the  pri¬ 
mary  site  for  data  access  will  receive  much  poorer  service 
than  the  other  nodes.  In.  fact,  it  may  be  necessary  to 
reduce  the  transaction  processing  load  at  the  primary  site 
node.  Second,  the  primary  site  can  become  saturated  just 
managing  locks.  With  class  2  transactions  and  the  locking 
overhead  rate  assumed  in  these  experiments,  an  extrapola¬ 
tion  shows  that  the  primary  site  will  saturate  if  there 
are  12  nodes  in  the  network.  Note  that  the  primary  site 
also  has  to  handle  a  disproportior ate  share  of  the  mes¬ 
sages.  The  time  units  used  for  handling  lock  messages 
(MFSCPU)  at  the  primary  site  should  al  so  be  it.ludei  it 
looking  at  primary  site  saturation.  An  extrapolation,  of 
the  total  overhead  (LOCKCPU  +  MESCP'U)  shows  that,  the  pri¬ 
mary  site  would  saturate  with  only  11  nodes  ii  the  r  ef- 
work . 

For  the  class  1  transactions,  on  the  other  hr  1  ,  each 
transaction,  required  much  less  locking  overhead  du^  to  the 
well-placed  lock  assumption.  Under  those  assimnt  i^r  r,  ,  the 
primary  site  would  not  bottler, eck  until  83  nodes  were  ir 


the  network. 
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4.4.  Percent  of'  Distributed  Transactions 

In  the  previous  simulation  runs,  ten  percent  of  the 
transactions  were  assumed  to  be  distributed,  while  the 
other  transactions  required  processing  at  the  local  nodes. 
In  this  section,  the  effects  of  varying  that  percentage  on 
the  optimum  granularity  and  choice  of  concurrency  control 
algorithms  are  examined.  Experiments  were  run  with  values 
of  0,  10,  26,  50,  >5,  and  100  for  the  percentage  of  dis¬ 
tributed  transactions  parameter  (PREDIST).  The  results 
are  presented  for  both  class  1  and  class  2  transactions. 

4.4-1.  Cl§ss  1  Transactions 

Changes  in  the  percentage  of  distributed  class  1 
transactions  affected  the  optimum  granularities  dif¬ 
ferently  for  the  different  concurrency  control  algorithms. 
In  addition,  as  that  percentage  increased,  the  choice  of  a 
'best'  algorithm  for  class  1  transactions  became  clearer. 

The  results  of  the  simulation  experiments,  varying 
the  PREDIST  parameter,  are  broken  into  the  following  four 
parts.  First  the  effects  of  the  locking  granularities  on 
the  four  models  are  discussed.  Next  the  four  models  are 
compared,  choosing  the  optimal  granularity  for  each  model 
for  each  setting  of  the  PREDIST  parameter.  Third,  the 
four  models  are  compared  under  alternate  network 
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assumptions .  in  the  final  set  of  exnerimer ts  ,  some-  mes¬ 
sages  useful  in  terms  of  crash  recovery  were  added  to  the 
primary  site  model. 

Effects  of  Lockitg  Granul ari  ty 

With  any  of  the  four  concurrency  control  algorithms, 
if  0%  of  the  transactions  were  distributed  (all  transac¬ 
tions  are  local),  the  maximum  useful  computer  utilization 
occurred  with  from  50  to  500  lockable  granules.  These 
results  were  similar  to  the  centralized  database  case  in 
Chapter  2. 

The  optimum  locking  granularity  for  three  of  the  four 
concurrency  algorithms  changed  as  the  percentage  of  dis¬ 
tributed  transactions  increased.  With  the  primary  site  2 
model,  however,  the  maximum  useful  computer  utiliz.atior 
occurred  at  or  near  500  granules. 

For  example,  in  figure  3-8,  the  shapes  of  the  useful 
1/0  curves  versus  the  number  of  locks  are  very  similar 
when  either  10%  or  75%  of  the  tran.sactiot  s  are  distri¬ 
buted.  For  the  other  three  models,  75%  distributed  tran¬ 
saction  curves  were  skewed  to  the  right  when  compared  t 
the  10%  curves. 

The  difference  between  the  models  is  that  u  the  pri¬ 
mary  site  2  model,  no  transactions  hold  locks  at  ere  node 


while  waiting  Tor  locks  at  at  other  rode.  As  the  porc-er.  tnge 
of  distributed  transactions  increased,  there  was  an 
increase  in  the  number  of  transactions  which  hold  leeks  at 
the  other  nodes  in  the  other  models.  Lower  granularity 
increased  the  number  of  incidences  of  this  condition  and 
hence  adversely  affected  the  performance  of  those  algo¬ 
rithms  . 

The  effects  of  varying  the  granularity  ar.d  the  per¬ 
centage  of  distributed  transactions  or  the  decentralized 
algorithms  was  even,  more  dramatic.  For  these  algorithms, 
a  granularity  from  1000  up  to  5000  locks  at  each  node  was 
required  to  orcduce  the  maximum  computer  utilization  as 
the  percentage  of  distributed  transactions  increased 
beyond  50%. 

The  need  for  finer  granularity  in  these  cases  was 
caused  by  two  effects.  First,  as  already  mentiored,  trnr  - 
sactions  hold  locks  at  one  node  while  waiting  for  locks  at 
a  second  node.  The  second  factor  affecting  the  granular¬ 
ity  in  these  models  was  that  with  coarse  granularity  mi  a 
high  percentage  of  distributed  tr an sactior s ,  mote  transac¬ 
tions  had  to  be  restarted. 


4.R.I.?.  Model_  Compar i sor  s 

Figure  3-9  shows  the  effects  op  the  useful  I/O  and 
the  average  response  time  of  the  percent  of  distributed 
transactions  for  each  of  the  four  concurrency  control 
algorithms.  (For  each  percentage,  and  for  each  algorithm, 
the  best  useful  I/O  and  average  response  time  regardless 
of  granularity  was  plotted.) 

The  'dish'  shaped  curves  for  USEFULIO  were  surpris¬ 
ing.  As  the  percentage  of  distributed  transaction s  was 
increased  up  to  50%,  all  four  models  showed  decreases  in 
useful  computer  utilization  due  to  the  additional  overhead 
(message  handling  and  locking)  required  to  run  distributed 
transactions.  However,  as  the  percentage  increased  beyond 
75%,  the  useful  computer  utilization  significantly 
increased  . 

That  increase  was  due  to  two  factors.  First,  the 
number  transactions  running  at  each  node  was  greatly 
increased.  For  example,  when  all  of  the  transactions  were 
distributed,  NHODFS  *  M T R A N  (60  in  the  simulation  runs) 
parts  of  transactions  were  active  at  each  node.  Second, 
the  average  transaction  size  at  each  node  was  smaller  as 
more  and  more  transactions  were  distributed. 

The  simulation  parameters  were  modified  to  keep  the 
number  and  sizes  of  active  transactions  at  each  node  con- 


Of  distributed  transactions 

(a ) 


Figaro  .-J:  Class  1  Transaction 
In  I  i  n  i  t  r  !>«ini1w  i  ^ 
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stant  as  the  percentage  of  distributed  transactions 
increased.  Only  when  both  parameters  were  held  fixed  did 
the  'dish'  shaped  curves  disaopear.  When  only  ore  of  the 
parameters  (NTRAN  or  AME AN-BMEA N )  were  held  constant,  hav¬ 
ing  all  transactions  distributed  produced  more  useful  I/O 
(and  CPU)  than  when,  only  50%  of  the  transactions  were  dis- 
tr ibuted  . 

The  average  response  time  curves  also  demonstrated 
dish  shaped  curves.  In  almost  all  cases,  the  second  pri¬ 
mary  site  model  (PS2),  produced  the  best  average  response 
time  of  the  four  models.  The  holding  of  locks  at  one  node 
while  waiting  for  locks  at  another  was  quite  detrimental 
to  the  throughput  of  the  system  and  occurred  with  increas¬ 
ing  frequency  in  the  other  three  models  as  the  percentage 
of  distributed  transactions  increased. 

When  fewer  than  half  of  the  transactions  were  non¬ 
local  the  SNOOP  and  PS2  models  produced  about  equal  useful 
I/O  and  average  response  times  and  were  slightly  better 
than  the  other  two  models.  However,  when  more  than  half 
of  the  transactions  were  non-local,  the  primary  site  2 
model  produced  si gr i f i c an tly  better  results  than  the  other 


three  models. 
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K  3.  Limited  Bardwiit. h 

The  above  observations  change  if  a  lower  network 
bandwidth  was  assumed.  All  four  concurrency  cot  trol  simu¬ 
lations  were  rerun  ,  varying  the  percentage  of  distributed 
transactions  with  a  message  bandwidth  of  6.  This  simu¬ 
lates  an  environment  where  only  six  messages  can  be  active 
in  the  Network  one  at  a  time.  The  tests  included  locking 
granularities  of  500,  1000,  2500  and  5000  locks  at  each 
node.  Additional  values  for  the  PERDIST  parameter  were 
also  tested  and  included  30,  35,  40  and  45  percent.  The 
results  are  shown  ir.  Figure  3-10. 

With  fewer  than  40?  of  the  transactions  being  non¬ 
local,  the  global  deadlock  detector  algorithm  produced 
more  useful  I/C  utilization  than  the  other  algorithms. 
When  45?  or  more  of  the  transactions  were  distributed,  the 
primary  site  2  model  again  produced  better  results.  Ir: 
these  cases,  the  extra  two  messages  for  locking  were  rot. 
that  significant;  a  distributed  transact i or  rnmiirod  at 
least  2  *  NSLAVFS  messages  anvwav. 

Note  also  that  the  'dish'  shape  curves  for  'if.KFUt.  1  "> 
have  practically  disappeared  with  a  limited  bandwidth  net¬ 
work.  In  these  cases  the  extra  network  delay  overhead 
caused  by  an  increased  PREDICT  parameter  more  than,  offset 
the  increases  in  tr  an  sac  t,  i  or  parallelism. 


SNOOP 
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4  •  4  •  2  •  ii  •  A 1.  ter  rat"  Primary  5  i  t  <•  Model 

Those  differences  between  the  SNOOP  nr.d  P. models 
would  be  even  less,  if  the  primary  site  models  required 
the  ’release  lock’  messar.es  to  he  sent  to  the  SLAVES.  In 
many  database  management  systems,  trarsactior  s  might  be 
backed  out  due  to  system  crashes,  changes  in  a  user’s  mind 
and  a  variety  of  other  reasons.  For  these  reasors,  it  may 
be  desirable  to  have  SLAVES  wait  until  the  transact  lot  has 
completed  at  all  nodes  before  ’committii.fi’  any  updates. 
In  these  types  of  database  management  svstems,  ’all  dor  o’ 
messages  similar  to  the  ’release  locks’  messages  must  be 
sent  to  the  SLAVES  ever:  with  the  primary  site  cor  c-urrcr  e y 
control  . 

The  primary  site  ?  model  was  modified  to  note  •  1  . 
send  "all  done"  messages  at  the  end  of  each  distri  but  •••  ; 
transaction.  With  that  modification  and  the  limit.."! 
bandwidth  network,  the  primary  site  ?  model  actually  pro¬ 
duced  slightly  less  useful  computer  utilizatior  th.ar  th" 
SNOOP  model,  regardless  of  the  peri.  er.  tag'*  of  d  i  :  -r  >■  :  n -r  •  >  i 
transact  ions. 

4.4.?.  Cl^ss  ?  Transactions 

With  class  ?  trarsactiors,  the  fires*,  gr  an  u  1  ar  i  t  v  was 
optimal,  regardless  of  the  percentage  of  distributed 


transactions.  Furthermore,  the  performance  of  the  con¬ 
currency  control  algorithms  also  changed  consistently  as 
the  percentage  of  distributed  transactions  increased. 

Figure  3-1 1(a)  shows  the  USEFULIO  for  the  four  algo¬ 
rithms  as  that  percentage  increased.  The  utilization  with 
the  decentralized  algorithms  was  affected  very  little  by 
the  increase  in  non-local  transactions.  Again,  a  slight 
increase  in  useful  computer  utilization  was  realized  due 
to  the  increased  distribution  of  transaction  processing. 

In  the  primary  site  algorithms,  on  the  other  hand, 
the  overall  computer  utilization  decreased  as  the  percen¬ 
tage  of  non-local  transactions  increased.  The  decrease 
was  most  dramatic  between  25  and  75  percent. 

The  same  advantage  for  the  decentralized  algorithms 
over  the  primary  site  algorithm  appeared  in  the  average 
response  time,  as  shown  in  figure  3—1 1 Cb) .  For  all  four 
algorithms  the  response  times  increase  as  the  percentage 
of  distributed  transactions  increased.  However,  the 
increase  was  much  less  for  the  decentralized  concurrency 
control  algorithms  than  for  the  primary  site  concurrency 
control  algorithms. 

Two  factors  caused  the  dramatic  difference  between 
the  primary  site  and  decentralized  models  for  class  2 
transactions:  the  transactions  were  all  small  and  the 
primary  site  crea.ted  a  bottleneck. 


Average  response  time 


Percent  of  non-locol  transactions 

(a ) 


( b) 

Figure  3-11:  Class  2  Tr.m  m<  t  i  ■  :.s 
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The  transactions  of  class  2  were  all  small  and  the 
results  in  Figure  3-11  were  for  the  finest  granularity. 
Under  those  conditions,  the  probability  of  success  on  a 
lock  request  was  extremely  high,  which  considerably 
reduced  the  advantage  that  the  primary  site  2  model  exhi¬ 
bited  for  class  1  type  transactions. 

The  second  factor  which  affected  the  performance  of 
the  concurrency  control  algorithms  was  the  bottleneck  at 
the  primary  site.  Over  7,000  time  units  out  of  a  possible 
20,000  were  used  for  locking  at  the  primary  site  when  all 
of  the  transactions  were  non-local.  Moreover,  all  tran¬ 
sactions  required  some  database  processing  at  that  primary 
site  and  were  thus  all  delayed  by  the  locking  overhead. 
This  bottleneck  became  increasingly  worse  as  the  percen¬ 
tage  of  distributed  transactions  increased. 

One  solution  to  the  bottleneck  problem  would  be  to 
offload  the  primary  site  concurrency  control  to  a  separate 
processor.  The  primary  site  2  simulation  was  modified  to 
test  this  strategy. 

Two  sets  of  experiments  were  run.  In  the  first  set, 
the  workload  and  network  parameters  remained  the  same  and 
the  concurrency  control  was  off-loaded  to  a  'seventh' 
node.  In  these  experiments,  the  primary  site  model  pro¬ 
duced  USEFULI0  and  average  response  times  very  similar  to 
the  decentralized  control  algorithm  results  shown  in 


figure  3-11.  In  fact,  the  primary  site  models  produced 
slightly  better  results  than  the  decentralized  models  when 
the  PREDIST  parameter  was  greater  than  50%. 

In  the  second  set  of  experiments,  the  6-node  data¬ 
base,  granules  and  transactions  were  distributed  on  a  5- 
node  network  with  a  sixth  node  being  used  only  for  the 
concurrency  control  .  The  results  were  again  similar  to 
those  in  figure  3-11  for  the  decentralized  models.  How¬ 
ever,  in  these  experiments  the  modified  primary  site 
models  produced  slightly  worse  results  than  the  decentral¬ 
ized  models. 

These  two  results  suggest  that  a  proper  database 
design  which  '  lowered  the  load  at  the  primary  site  could 
perform  equally  as  well  as  the  decentralized  algorithms. 

The  PREDIST  simulation  experiments  for  class  tran¬ 
sactions  were  repeated  with  a  limited  bandwidth  n«‘  i  w  a  !■:  . 
In  these  experiments,  the  primary  site  models  were  host  if 
more  than  50%  of  the  transactions  were  dirtri bid ed  .  Is 
those  cases,  the  primary  site  models  actually  sent  fewer 
locking  messages  than  the  decentralized  algor  i  t  hmr, . 

£ .  5  .  N e  twor  k  P a r  a m >  t  < •  r  :■ 

In  this  section  ,  the  »•«•;  <i  1 1  r  of  v :  rvi  r  r  f  i  v  •  -  <  t  w  •  - 
input  parameters  ar<  r>  q  .r  led  .  I  r  *  j  :  .  v  i.-.u-  runs  :  »  <• 
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MESRATE,  or  the  length  of  time  it  takes  to  send  a  message, 
was  fixed  at  3  simulation  time  units.  The  MESBDWT,  or 
number  of  simultaneously  active  messages,  was  effectively 
set  to  oo,  by  setting  the  MESBDWT  parameter  to  1000. 

The  data  transfer  parameters,  PRETRAN  and  PREDATT, 
were  also  fixed  in  all  of  the  previous  simulation  experi¬ 
ments.  In  those  experiments  JJ0  5E  (PRETRAN)  of  the  distri¬ 
buted  transactions  sent  25%  (PREDATT)  of  their  entities  to 
other  nodes.  The  DATARATE  parameter  was  set  to  .05,  which 
determined  how  long  it  took  to  send  data  entities  across 
the  network. 

One  other  network  parameter,  the  MESSCPURATE,  while 
not  affecting  the  network  directly,  did  affect  tie  message 
or  network  overhead  required  at  each  node.  For  all  of  the 
previous  experiments,  a  message  CPU  rate  of  .01  (300 
microseconds)  was  assumed. 

Simulations  were  run  with  MESRATES  of  1  (30  msecs),  3 
(90  msecs)  and  10  (300  msecs,  similar  to  the  ARPANET). 
The  simulations  were  also  run  with  MESBDWT  of  100,  50,  10 
and  6.  The  DATARATE  ex  per i men ts  included,  0.05,  0.1,  0.25 
and  0.5.  The  message  CPU  rate  parameter  was  set  to  .01 
(300  microseconds) ,  0.05  (1.5  msecs),  0.1  (7  msecs)  and 
0.3  (9  msec  s ) . 

Class  2  transactions  required  much  greater  use  of  the 
network  resources  than  class  1  transactions.  Thus 
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variations  in  the  network  parameters  had  a  much  greater 
effect  on  class  2  transactions . 

4 .5.K  Class  _1_  Transactions 

The  significant  effects  of  lowering  the  bandwidth  and 
varying  the  percentage  of  distributed  transactions  have 
already  been  reported  in  section  4.5.  Varying  the  MES- 
RATE,  MESBDWT  and  MESC PUR ATE  parameters  had  little  effect 
on  the  other  observations  reported. 

The  effects  of  varying  the  message  rate  parameter 
were  slight.  The  results  with  message  rates  of  1  and  3 
were  almost  identical  for  all  four  concurrency  control 
algorithms.  A  MESRATE  of  10  resulted  in  about  a  5% 
decrease  in  useful  computer  utilization  for  the  primary 
site  models  and  almost  no  change  in  the  useful  utilization 
for  the  distributed  concurrency  control  models. 

MESBDWT  settings  of  100  and  50  produced  useful  com¬ 
puter  utilizations  and  average  response  time  identical  to 
the  infinite  setting  1000  previously  used.  Slight  drops 
in  the  useful  1/0  and  CPU  utilizations  were  realized  with 
message  bandwidths  of  10  and  6.  The  drops  with  a  message 
bandwidth  of  10,  however,  were  1  ess  than  1  %  and  not  con¬ 
sidered  significant. 
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A  message  bandwidth  of  6  did  produce  more  noticeable 
reductions  in  the  useful  I/O  and  CPU  utilizations.  The 
drops  in  useful  utilization  were  only  about  2-3?  with  the 
primary  site  and  SNOOP  models.  The  wound-wait  model,  on 
the  other  hand,  realized  a  drop  of  almost  7?.  Although 
the  primary  site  models  sent  more  lock  messages,  they  were 
mainly  sent  one  message  at  a  time.  A  wound  or  kill,  how¬ 
ever,  resulted  in  NSLAVE  messages  being  sent,  or  broadcast 
over  the  network.  These  "bursts"  of  messages  were 
effected  more  by  the  lower  bandwidth  than  the  greater 
number  of  individual  messages  in  the  primary  site  models. 
In  the  SNOOP  model,  on  the  other  hand,  a  conflict  only 
required  1  message.  A  kill  still  required  NSLAVE  mes¬ 
sages,  but  occurred  very  rarely. 

The  change  of  the  DATARATE  parameter  had  little 
effect  on  class  2  transactions.  When  the  DATARATE  was  .5 
and  all  of  a  distribute  transaction's  entities  were  sent 
across  the  network,  a  decrease  in  the  computer  utilization 
of  only  about  7?  was  realized. 

With  an  extremely  fast  DATARATE  parameter  (.05  as  in 
the  canonical  scenarios),  changes  in  the  number  of  tran¬ 
sactions  which  transferred  data,  or  the  amount  of  data 
they  transferred  produced  curves  almost  identical  to  those 
shown  in  figures  3-^,  3-5  and  3-6 ,  :;r.d  arc  not  repeated 
here.  A  slight  drop  in  useful  I/O  and  CPU  time  was 
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observed  as  the  amount  of  data  transferred  increased  for 
both  classes  of  transactions  and  for  each  of  the  con¬ 
currency  control  algorithms.  However,  even  if  all  of  the 
distributed  transactions  transfer  all  of  their  data,  the 
decrease  was  less  than  3%- 

Note  that  these  results  do  not  imply  that  data 
transferred  is  not  an  important  parameter  in  a  distributed 
database.  In  the  models  considered  here,  data  transfer 
resulted  in  a  waiting  time  for  that  transfer  to  complete. 
Under  these  assumptions,  no  additional  I/O  or  CPU 
resources  were  used  in  transferring  data;  it  was  assumed 
that  use  of  these  resources  is  already  included  in  tran¬ 
saction  processing.  Furthermore,  with  the  fast  DATARATE 
assumed,  even  a  transaction  accessing  500  entities  would 
wait  on  the  transaction  wait  queue  for  only  25  time  units. 

When  the  DATARATE  was  increased  from  .05  to  .5,  and 
the  PRETRAN  and  PREDATT  parameters  were  varied,  a  larger 
drop  in  useful  CPU  and  I/O  utilization  was  observed.  At 
the  optimum  granularity,  a  drop  of  almost  7  %  in  computer 
utilization  was  realized.  In  these  cases,  the  larger 
transactions  might  wait  on  the  CPU  queues  for  ?r0  time 
units,  a  significant  portion  of  their  lifetimes. 

Changes  in  the  i  CRATE  parameter  had  the  greatest 
effect  on  the  useful  computer  util:  zat.  i  •  r  output  pen  ame- 
ters.  In  the  primary  rile  model:  ,  a  dr  err  nr  e  of  nlmo-t  r)7 
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was  realized  when  the  message  rate  was  increased  to  .3 
(almost  9  msecs).  With  that  same  message  rate,  the  useful 
computer  utilization  only  dropped  by  about  4 %  in  the 
decentralized  models. 

In  class  1  transactions,  the  critical  resources  ar 
the  I/O  and  CPU  resources  at  the  nodes  and  not  the  network 
resources.  Thus  the  heavy  message  traffic  of  the  primary 
site  models  is  impacted  much  more  by  the  message  CPU  rate 
than  the  other  network  parameters. 

5. 2.  Class  2  Transactions 

The  MESRATE,  ME5C PURATE ,  MESBDWT,  and  DATARATE  param¬ 
eters  were  also  varied  for  class  2  transactions .  Changes 
in  the  first  three  parameters  affected  the  performance  of 
all  four  concurrency  control  algorithms.  The  DATARATE 
parameter  had  practically  no  effect  on  the  processing  of 
class  2  transactions. 

The  USEFULIC  end  the  average  response  time  (in 
parenthesis)  is  given  in  Table  3-11  for  each  of  the  four 
concurrency  control  algorithms.  In  the  first  set,  the 
MESRATE  parameter  was  varied  while  the  KESCPURATE  and 
MESI'DV.'T  were  fixed  at  .01  and  1000  respectively.  As  the 
message  rate  increases,  the  gap  between  the  primary  site 
and  decentralized  control  models  widened. 
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Table  3-11:  Effects  of  Network  Parameters 
PS  1  PS2  WW  SNOOP 


MESRATE 

1 

94994(63) 

94720(63) 

95839(61  ) 

97037(62) 

3 

93996(64 ) 

93319(64 ) 

97134(61) 

96204(62) 

10 

87998(67) 

88078(67 ) 

96037(63  ) 

96875(62) 

MESCPURATE 
.01  93996(64 ) 

93319(64) 

97145(65) 

96204 (62) 

.05 

88953(67) 

88767(68) 

95048(63  ) 

94710  (64  ) 

.  1 

83273(72  ) 

83086(73) 

92394(65) 

91860(65) 

.3 

58676(102) 

58372 ( 102) 

83313(72  ) 

82690(73) 

MESOULP 

1000-50 

93996(64 ) 

93319(64 ) 

97145(6  1  ) 

96204(62) 

10 

82804(72) 

83234(72) 

96827(6?) 

96979(62) 

6 

55200(108) 

55692(108) 

95948(63) 

96242(62) 

A  more  dramatic  change  occurred  when  the  message  CPU 
rate  was  varied.  During  these  experiments,  the  MESRATE 
and  MESBDWT  were  fixed  at  3  and  1000  respectively.  With  a 
3  millisecond  cost  (MESCPURATE  =  .1)  for  sending  a  mes¬ 
sage,  the  primary  site  models  produced  only  89%  of  the 
useful  computer  utilization  that  was  realized  with  the 
decentralized  concurrency  control  algorithms.  With  a  9 
msec  message  rate  (MESCPURATE  =  .3)  this  percentage  drops 
to  72%. 


Similarly,  a  dramatic  change  in  USF'F'JLIO  and  response 
time  for  the  primary  site  models  was  realized  as  the  mes¬ 
sage  bandwidth  was  restricted.  For  these  experiments,  the 
message  rate  and  message  CPU  rate  parameters  were  fixed  at 
3  and  .01  respectively.  Note  that  while  the  performance 
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of  the  primary  site  models  was  heavily  affected  by  the 
restricted  bandwidth,  the  decentralized  models  were  hardly 
affected  at  all.  This  result  is  due  to  the  fact  that  with 
the  primary  site  models,  almost  40,000  more  messages  were 
sent  than  with  the  decentralized  algorithms. 

Variations  in  the  DATARATE,  PRETRAN  and  PREDATT 
parameters  had  little  or  no  effect  on  the  performance  of 
the  four  concurrency  control  algorithms.  Class  2  transac¬ 
tions  were  all  small.  Thus  any  wait  on  the  data  transmis¬ 
sion  queue  was  also  small  even  if  all  of  the  distributed 
transactions  transferred  all  of  their  data. 

As  expected,  the  performance  of  a  primary  site  con¬ 
currency  control  algorithm  deteriorated  as  restrictions 
were  placed  on  the  network.  The  effect  of  the  restric¬ 
tions  on  the  wound-wait  and  SNOOP  algorithms  was  much 
smaller . 

4.6.  Canonical  Scenario  Revisited 


In  section  4.1,  the  effects  of  the  different  con¬ 
currency  control  algorithms  on  computer  utilization  and 
average  response  times  with  two  different  classes  of  tran¬ 
sactions  were  presented.  In  those  experiments  a  very 
fast,  low  overhead  and  high  bandwidth  network  was  assumed. 
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Subsets  of  those  eases  were  rerun  under  alternate 
network  assumptions.  For  the  results  presented  in  Figure 
3-12,  the  MESRATE  was  assumed  to  be  10  simulation  time 
units  or  about  .3  seconds.  The  MESBPWT  parameter  was  set 
to  6,  while  the  MESCPURATE  was  set  to  .1,  simulating  a 
cost  of  about  3  msecs  to  handle  a  message  at  a  node. 
These  settings  roughly  resemble  the  ARPANET  parameters. 
Note  that  the  simulations  were  not  run  for  all  of  the 
granularities. 

In  section  -h .  1  for  class  1  transactions  with  finer 
granularities,  no  one  concurrency  control  algorithm  seemed 
dominant.  Figure  3-12  shows,  on  the  other  hand,  that  the 
decentralized  algorithms,  the  wound-wait  or  SNOOP,  produce 
significantly  better  machine  utilization  than  the  primary 
site  models.  The  drop  of  about  9%  realized  with  the  pri¬ 
mary  site  models,  when  compared  to  the  decentralized 
models,  is  consistent  with  the  drop  observed  in  section 
4.6,  when  only  one  of  the  network  parameters  was  varied. 

The  advantage  of  the  decentralized  algorithms  for 
class  1  type  transactions  shown  in  section  4  .  1  became  oven 
more  apparent  when  a  slower  network  was  assumed.  Note, 
however ,  that  under  the  given  network  parameter  the  useful 
computer  utilizations  for  even  the  decentralized  algo¬ 
rithms  were  much  lower  than  with  the  original  ret  work 
parameters.  Thus,  regard  loss  of  the  concurrent  y  control 
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algorithm,  a  'distributed  database  where  nil  transactions 
are  very  small  is  perhaps  not  suitable  for  a  slow  computer 
networ  k . 


5.  CONCLUSIONS 

As  with  the  centralized  database  concurrency  control, 
the  algorithms  and  parameters  of  the  concurrency  control 
for  a  distributed  database  are  also  application  and  system 
dependent.  In  this  section  the  major  conclusions  on  the 
locking  granularity,  the  algorithms  for  class  1  and  class 
2  type  transactions  are  reviewed. 

5.U  Locking  Granularity 

In  general,  a  finer  granularity  is  required  for  lock¬ 
ing  in  a  distributed  database  than  in  a  centralized  data¬ 
base.  However,  if  the  locks  are  well-placed  with  respect 
to  the  accessing  transactions,  the  finest  granularity  is 
still  not  worth  the  additional  concurrency  produced. 

The  need  for  finer  granularity  in  a  distributed  data¬ 
base  was  caused  by  one  major  factor:  transactions  held 
locks  at  one  node  while  waiting  for  locks  at  another  node. 
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When  that  condition  was  avoided  with  the  PS2  model,  much 
coarser  granularity  was  acceptable. 

Even  that  model,  however,  required  slightly  less 
coarse  granularity  than  was  required  for  a  centralized 
database  under  the  same  assumptions.  In  the  centralized 
database,  10  to  100  granules  produced  the  maximum  useful 
computer  utilization  under  the  well-placed  lock  assump¬ 
tions.  In  the  PS2  distributed  database,  100  to  1000 
granules  are  required.  In  the  PS 2  model  and  very  coarse 
granularity,  many  distributed  transactions  have  to  release 
and  rerequest  locks  at  a  low  number  nodes.  The  additional 
locking  overhead  makes  coarse  granularity  unacceptable. 

5.2.  Class  2  Transactions 

If  the  number  c*f  distributed  transactions  is  low 
(£10%)  and  the  network  is  considered  lightly  loaded,  the 
performance  of  all  four  concurrency  control  algorithms  was 
very  similar  for  class  1  transactions. 

As  the  percentage  of  distributed  transactions 
increase,  the  primary  site  2  model  produces  better  com¬ 
puter  utilization  and  average  response  times  than  either 
of  the  decentralized  models.  In  these  cases,  the  extra 
two  messages  required  in  the  primary  site  model  represent 
a  lower  percentage  of  overhead  since  the  transactions  will 
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be  sending  at  least  2  *  NSLAVE  messages  anyway.  Moreover, 
this  overhead  is  more  than  offset  by  the  ability  to  avoid 
inactive  nodes. 

When  the  bandwidth  of  the  network  is  lowered  and  the 
number  of  distributed  transactions  is  low,  however,  the 
decentralized  concurrency  control  models  produce  better 
computer  utilization  and  response  time  than  the  primary 
site  models.  In  these  cases,  the  primary  site  lock  mes¬ 
sage  overhead  interferes  with  the  normal  transaction  pro¬ 
cessing  . 

The  above  two  conclusions  come  into  conflict  as  the 
percentage  of  distributed  transactions  increases  and  a  low 
bandwidth  network  is  assumed.  The  simulation  results 
indicate  that  with  a  low  bandwidth  network,  the  SNOOP  dis¬ 
tributed  concurrency  control  algorithm  is  best  when  less 
than  45%  of  the  transactions  are  distributed.  When  more 
than  45%  of  the  transactions  are  distributed,  the  primary 
site  2  model  is  preferred. 

When  the  percentage  of  distributed  transactions  is 
less  than  10%,  the  SNOOP  and  wound-wait  algorithms  perform 
equally  well.  However,  as  that  percentage  increases,  the 
SNOOP  model  results  in  better  performance  than  the  wound- 
wait  model.  As  expected  in  these  cases,  the  percentage  of 
conflicts  increases  and  has  a  more  adverse  effect  on  the 
wound-wait  algorithm. 
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5. 3-  Class  2  Transactions 

Under  the  class  2  transaction  assumption,  all  of  the 
transactions  are  small  and  randomly  access  entities  in  the 
database.  In  these  cases,  the  decentralized  concurrency 
control  models  consistently  produce  better  response  times 
and  useful  I/O  and  CPU  utilization  than  the  primary  site 
models.  With  extremely  small  transactions,  the  extra  mes¬ 
sages  in  the  primary  site  models  represent  a  significant 
delay  factor.  Furthermore,  the  small  transactions  make 
the  probability  of  conflict  and  restart  very  low  with  the 
dectralized  concurrency  control  algorithms. 

Also,  with  only  small  transactions  and  random  lock 
placement  assumptions,  the  locking  overhead  is  a  signifi¬ 
cant  factor.  When  all  of  this  overhead  is  concentrated  at 
one  site,  that  site  can  bottleneck  as  either  the  number  of 
sites  in  the  network  or  the  percentage  of  distributed 
transactions  increase. 

The  above  observations  for  class  2  transactions  hold 
even  under  optimistic  network  conditions.  As  the  network 
parameters  become  restrictive,  the  advantages  of  the 
decentralized  concurrency  control  become  even  more  evi¬ 
dent  . 

The  wound-wait  and  SNOOP  concurrency  control  models 
produced  extremely  similar  results  for  class  2  transac- 
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tlons.  This  similarity  was  due  to  two  factors.  First, 
the  small  transactions  are  involved  in  very  few  conflicts 
and  thus  the  probability  of  a  transaction  blocking  and 
being  blocked  by  an  older  distributed  transaction  is 
extremely  small.  The  second  factor  is  that  a  transaction 
is  much  more  likely  to  be  blocked  by  an  older  transaction 
(in  which  case,  no  wound  or  kill  takes  place)  since  the 
individual  sites  operate  with  a  preclaim  locking  strategy. 


CHAPTER  H 

CONCLUSIONS 


The  major  goal  of  this  thesis  was  to  examine  the 
effects  of  concurrency  control  on  the  performances  of 
database  management  systems.  The  effects  of  concurrency 
control  on  performance  are  dependent  on  two  conflicting 
factors.  On  the  other  hand,  the  database  system  perfor¬ 
mance  can  be  enhanced  by  allowing  concurrent  users  simul¬ 
taneous  access  to  the  database.  Both  the  useful  computer 
utilization  and  the  average  response  time  can  be  improved 
by  supporting  a  multiple  user  environment. 

On  the  other  hand,  the  database  system  performance 
might  be  degraded  due  to  extensive  concurrency  control 
overhead.  The  concurrency  control  overhead  is  due  to  the 
computer  resources  utilized  in  some  type  of  "locking". 
The  "locking"  is  used  to  prevent  one  user  of  the  database 
from  interfering  with  the  processing  of  another  user. 

In  the  first  section  of  this  chapter,  the  major  con¬ 
clusions  from  Chapters  2  and  3  are  reviewed.  In  the  next 
section  the  applications  of  these  conclusions  to  other 
concurrency  control  implementations  are  projected  and 
several  areas  of  further  research  are  suggested. 
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SUMMARY  OF  PREVIOUS  CONCLUSIONS 

Simulation  models  were  used  to  study  the  performance 
effects  of  concurrency  control  in  both  centralized  and 
distributed  databases. 

1-1-  CENTRALIZED  DATABASES 

In  a  centralized  database,  all  database  activity, 
including  concurrency  control,  are  processed  on  a  single 
computer  system.  A  simulation  model  was  used  to  determine 
the  optimum  granularity  for  locking,  the  effects  of  a 
variety  of  workload  and  system  characteristics,  the 
effects  of  a  lock  hierarchy,  and  the  effects  of  a  "pre¬ 
claim"  versus  a  "claim  as  needed"  locking  strategy. 

The  overall  conclusions  on  locking  granularity  are 
application  dependent  as  shown  in  Table  4-1. 

Table  4-1  Locking  Granularity 

small  large  mixed  sized 

Transactions  Transactions  Transactions 

Coarse  gran.  Coarse  gran.  Coarse  gran. 

Fine  gran.  Coarse  Gran.  Lock  Hierarchy 

with  Fire  gran. 


Wei 1-pl aced 

Random 

placement 
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In  many  cases  coarse  granularity,  such  as  file  or 
relation  locking,  is  preferred.  However,  if  random  lock 
placement  is  assumed  and  all  of  the  transactions  are 
small,  the  coarse  granularity  is  unacceptable  and  fine 
granularity  locking  must  be  implemented. 

If  random  lock  placement  is  assumed  and  a  variety  of 
different  sized  transactions  are  present  in  the  workload, 
a  lock  hierarchy  should  be  used.  In  such  a  hierarchy, 
some  large  transactions  can  lock  large  granules,  while 
other  small  transactions  lock  much  finer  granules.  If  a 
transaction  were  to  set  more  than  1 %  of  the  smaller  locks 
under  any  one  large  lock,  it  would  be  more  efficient  for 
that  transaction  to  simply  set  the  one  large  lock. 

In  a  preclaim  locking  strategy,  a  transaction 
acquires  all  of  its  locks  at  the  beginning  of  the  transac¬ 
tion.  In  a  claim  as  needed  locking  strategy,  the  locks 
are  acquired  as  the  respective  parts  of  the  database  need 
to  be  accessed.  With  a  few  exceptiors,  the  preclaim  stra¬ 
tegy  produced  better  machine  utilization  than  the  claim  as 
needed  model.  However,  the  above  conclusions  on  locking 
granularity  and  a  lock  hierarchy  hold,  regardless  of 
whether  a  proclaim  or  claim  as  needed  strategy  is  used. 


].?.  Distributed  Databases 

In  a  distributed  database,  the  database  activity, 
including  the  concurrency  control,  are  processed  on 
several  computer  systems  connected  by  a  network.  Four 
concurrency  control  algorithms  were  simulated  in  order  to 
study  their  performance  effects  under  a  variety  of  work¬ 
load  and  network  conditions. 

Two  of  the  algorithms  simulated  involved  a  central¬ 
ized  concurrency  control  where  locking  for  the  entire- 
database  was  controlled  at  one  primary  site  in  the  net¬ 
work.  In  the  "primary  site  1"  model,  transactions  acquire 
the  locks  needed  at  each  node  or  site  in  some  fixed  order. 
If  the  locks  for  one  node  are  denied,  the  "blocked"  tran¬ 
saction  waits  for  those  locks  while  holding  locks  on  lower 
ordered  nodes. 

In  the  alternate  centralized  control  model,  the  "pri¬ 
mary  site  2"  model,  the  locks  needed  at  each  node  arc 
again  acquired  in  some  fixed  order.  However,  in  thin, 
case,  if  the  locks  for  one  node  are  denied,  the  'Mocked' 
transaction  releases  all  currently  held  locks  while-  writ¬ 
ing  for  access  to  the  locked  granules. 

The  other  two  algorithms  simulated  involved  decen¬ 
tralized  concurrency  control  where  locking  for  the  portion 
of  the  database  at  each  node  was  controlled  at  that  node. 
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In  the  "wound-wait"  model,  deadlock  is  prevented  by 
"wounding"  any  "young"  transaction  that  dares  to  block  an 
"older"  transaction.  The  wound  is  transferred  to  all 
sites  where  the  wounded  transaction  is  active.  If  a 
wounded  transaction  is  blocked  at  any  site  by  an  "older" 
transaction,  the  wounded  transaction  releases  its  locks  at 
each  site  and  is  then  restarted. 

In  the  other  decentralized  control  algorithm, 
deadlocks  are  resolved  by  a  global  deadlock  detector,  or 
"SNOOP".  If  a  deadlock  exists,  a  transaction  is  picked 
which  also  releases  its  locks  at  each  site  and  is  then 
restarted  . 

Which  model  is  best  in  terms  of  its  effect  on  the 
distributed  database  system  performance  is  also  applica¬ 
tion  dependent  as  shown  in  Table  4-2.  Class  1  transac¬ 
tions  refer  to  a  workload  environment  where  the  locks  are 
assumed  to  be  well-placed  with  respect  to  the  accessing 
transactions  and  that  those  transactions  are  of  mixed 
sizes.  Class  2  transactions  refer  to  workloads  where  all 
of  the  transactions  are  small  and  random  placement  of 
locks  i s  assumed  . 

In  some  cases,  it  appears  that  the  concurrency  con¬ 
trol  mechanism  is  not  a  significant  factor  in  the  database 
system  performance.  For  class  2  transactions,  additional 


Table  4-2:  Concurrency  Control  Models 

C 1  a  s s  1  Class? 

Transactions  Transactions 

Fast  Net.  Primary  Site  or  Primary  Site  or 

Most  trans.  Decentralized  Decentralized 

local 

Slow  Net.  SNOOP  Decentralized 

Most  trans. 

local 

Fast  Net.  Primary  Site  2  Decentralized 

Most  trans. 

non-local 

Slow  Net.  Primary  Site  2  Primary  Site 

Most  trans. 

non-local 

simulation  runs  showed  that  the  preference  for  decentral¬ 
ized  concurrency  control  could  be  offset  by  reducing  the 
database  load  at  the  primary  site.  Thus  in  these  cases, 
the  choice  of  concurrency  control  algorithm  may  again  not 
be  significant. 

For  class  1  transactions,  when  most  of  the  transac¬ 
tions  only  required  local  processing  and  a  slower,  lower 
bandwidth  network  is  assumed ,  the  f.NDOF  algorithm  i pre¬ 
ferred.  In  this  case,  the  SNOCi'  model  was  favored  St  .a::. 
of  the  lower  number  of  mess, ages  required. 

Also  for  class  1  t  ?  ansae  lions. ,  if  most  of  ire  •  ran- 
sactions  are  non-local  or  distributed,  the  primary  site 
model  is  preferred.  The  advantage  of  the  primary  site 
model  is  that  only  in  that  model  does,  a  Iranr.i.-t  i  .a. 


release  locks  at  all  other  nodes  while  waiting  for  locks 
at  one  node.  In  the  other  three  models,  it  is  possible 
for  a  transaction  to  hold  locks  at  one  node  while  waiting 
for  locks  at  another  node. 

Another  factor  which  favors  the  primary  site  2  model 
over  the  decentr al i zed  models  when  most  transactions  are 
distributed,  is  that  in  those  cases,  the  primary  site 
model  no  longer  produces  heavier  message  traffic. 

The  distributed  database  simulations  indicated  that 
some  of  the  coarse  granularity  conclusions  for  the  cen¬ 
tralized  database  do  not  hold  for  the  distributed  data¬ 
base.  However,  under  the  well-placed  lock  assumptions, 
the  finest  granularity  is  still  worse  than  a  medium  granu¬ 
larity  concurrency  control. 

Z-  future  DIRECTIONS 

The  results  of  the  simulation  studies  suggest  several 
areas  for  future  study.  Two  such  areas  would  be  to  extend 
the  lock  hierarchy  and  the  claim  as  needed  locking  models 
to  a  distributed  database.  Another  study  would  be  to 
investigate  the  multiple  copy  problem  in  the  distributed 
database  model.  The  results  of  the  simulations  in  this 
study  do,  however,  provide  some  insights  in  each  of  these 
areas. 
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For  the  centralized  database,  the  conclusion  was 
reached  that  if  the  locks  are  well-placed,  coarse  granu¬ 
larity  is  preferred  and  a  lock  hierarchy  is  thus  not  bene¬ 
ficial.  In  those  cases,  it  was  mere  efficient  to  just  use 
one  level  of  coarse  locking  (10  to  100  locks).  In  the 
distributed  database  cases,  finer  granularity  (500  to  1000 
locks)  is  required  even  if  well-placed  locks  are  assumed. 
A  lock  hierarchy  in  that  granularity  range  was  beneficial. 
Thus  a  lock  hierarchy  at  each  node  for  a  distributed  data¬ 
base  might  be  more  useful  than  in  a  centralized  database. 
This  projection  could  be  verified  by  simple  extensions  to 
the  distributed  database  simulations  similar  to  the  exten¬ 
sion  in  chapter  2. 

A  claim  as  needed  locking  strategy  may  be  required  if 
the  entities  to  be  accessed,  iind  hence  the  granules  to  be 
locked,  are  dependent  upon  the  values  of  entities  previ¬ 
ously  accessed.  With  a  claim  as  needed  locking  strategy 
in  a  distributed  database,  the  primary  site  models  might 
require  two  messages  for  every  lock  set.  In  addition, 
with  claim  as  needed  locking,  the  primary  site  models 
would  also  have  to  prevent  or  detect  dead1  'ek  and  thus 
lose  one  of  their  advantages  over  the  decentralized 
models.  Therefore,  for  claim  as  needed  locking,  the  pri¬ 
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The  comparison  of  the  two  decentralized  concurrency 
control  algorithms  might  be  affected  by  a  claim  as  needed 
locking  strategy.  With  the  preclaim  locking  strategy  and 
the  wound-wait  model,  relatively  few  transactions  were 
wounded  since  there  was  a  high  probability  that  a  blocking 
transaction  was  older  than  the  blocked  transaction.  With 
a  claim  as  needed  locking  strategy,  however,  a  transaction 
would  request  locks  at  several  different  instances  during 
its  lifetime.  Thus,  the  probability  of  being  blocked  by  a 
younger  transaction  would  increase.  Consequently,  the 
global  deadlock  detecter  or  SNOOP  algorithm  would  probably 
be  better  than  the  wound-wait  algorithm  in  a  claim  as 
needed  locking  environment.  Simple  simulation  extensions 
could  also  be  used  to  test  that  hypothesis. 

The  multiple  copy  concurrency  problem  was  discussed 
in  Chapter  1.  In  a  distributed  database,  it  is  sometimes 
advantageous  to  replicate  parts  of  the  database  at  several 
of  the  nodes  in  the  network.  The  multiple  copy  con¬ 
currency  problem  is  to  ensure  that  the  replicated  copies 
are  kept  mutually  consistent  or  identical  during  simul¬ 
taneous  user  updates. 

The  four  distributed  database  concurrency  control 
simulations  could  be  applied  to  the  multiple  copy  problem 
as  follows.  Assume  that  the  entire  database  is  replicated 
at  each  node.  Gone  transactions  are  'read-only'  t.ransac- 


tions  and  just  need  to  access  the  data  at  one  rode.  These 
transactions  can  be  considered  the  local  transactions  in 
the  simulations.  The  'write'  transaction,  on  the  other 
hand,  must  cause  activity  at  each  node  and  thus  may  be 
considered  the  distributed  transactions. 

In  this  inter pretation ,  the  PREDIST  parameter  would 
represent  the  percentage  of  update  trar. sactions.  Under 
the  above  interpretation,  the  conclusion  summarized  in 
Table  4-2  can  be  applied  to  the  multiple  copy  problem.  If 
the  database  is  dominated  by  updates  (i.e.  most  transac¬ 
tions  non-local)  and  the  updates  are  relatively  large  and 
sequential  in  nature  (i.e.  Class  1  transactions),  a  pri¬ 
mary  site  concurrency  control  is  suggested.  Thus  all 
transactions  would  first  acquire  locks  at  a  'primary  copy' 
of  the  data. 

However,  if  all  of  the  updates  are  small  and  random 
in  nature  (i.e.  Class  2  transactions)  or  most  of  the 
transactions  are  'read-only'  with  respect  to  this  database 
portion  (i.e.  local  transactions)  then  a  decentralized 
concurrency  control  is  suggested  (or  is  at  least  accept¬ 
able).  In  a  decentralized  concurrency  control,  the 
updates  would  request  locks  at  each  rode  and  proceed  with 
the  updates.  However,  the  updates  would  have  to  to 
prepared  to  be  rolled  back  due  to  conflicts  with  other 
updates . 
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However ,  the  above  analysis  is  an  over  simplification 
of  the  multiple  copy  problem  in  a  distributed  database. 
One  over  simplification  is  that  other  concurrency  control 
solutions  exist  to  the  multiple  copy  problems  which  are 
not  directly  extendible  to  the  internal  database  con¬ 
sistency  problems.  These  algorithms  must  also  be  compared 
with  the  simulated  algorithms . 

More  importantly,  the  above  analysis  assumes  a  fixed 
distribution  of  the  copies  in  the  distributed  database. 
In  other  words,  the  database  is  fully  replicated  and  then 
the  number  of  updates  and  the  network  parameters  are 
varied.  But  the  optimum  replication  of  the  data  actually 
depends  on  the  proportion  of  updates  and  the  network 
parameters.  In  fact  the  optimum  replication  of  the  data 
may  be  influenced  by  the  multiple  copy  concurrency  con¬ 
trol  . 

These  analysis  deficiencies  cannot  be  over  come  by 
straightforward  extensions  to  the  existing  simulation 
models.  Instead  a  more  complete  model  should  be  developed 
to  jointly  study  the  database  consistency  and  multiple 
copy  problems. 

In  summary,  this  dissertation  provides  insights  into 
the  effects  of  concurrency  control  on  database  system  per¬ 
formance  under  a  wide  variety  of  conditions.  The  results 
of  the  dissertation  can  be  usc-d  to  guide  concurrency 
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